主頁 > 軟體設計 > 暢購商城(十四):秒殺系統「下」

暢購商城(十四):秒殺系統「下」

2020-10-19 17:56:39 軟體設計

好好學習,天天向上

本文已收錄至我的Github倉庫DayDayUP:github.com/RobodLee/DayDayUP,歡迎Star

  • 暢購商城(一):環境搭建
  • 暢購商城(二):分布式檔案系統FastDFS
  • 暢購商城(三):商品管理
  • 暢購商城(四):Lua、OpenResty、Canal實作廣告快取與同步
  • 暢購商城(五):Elasticsearch實作商品搜索
  • 暢購商城(六):商品搜索
  • 暢購商城(七):Thymeleaf實作靜態頁
  • 暢購商城(八):微服務網關和JWT令牌
  • 暢購商城(九):Spring Security Oauth2
  • 暢購商城(十):購物車
  • 暢購商城(十一):訂單
  • 暢購商城(十二):接入微信支付
  • 暢購商城(十三):秒殺系統「上」
  • 暢購商城(十四):秒殺系統「下」

防止秒殺重復排隊

回顧一下上一篇文章中講到的下單的流程,當用戶點擊下單之后,用戶名和商品id就會組裝成一個SeckillStatus物件存入Redis佇列中等待被處理,這個程序叫做排隊,所以說,只要用戶點擊了一次下單后不論最后是否下單成功,他都會進入到排隊的狀態,如果用戶重復點擊下單,那么Redis佇列中就會有很多個相同的SeckillStatus物件,也就是一個用戶排隊多次,這顯然是不符合邏輯的,一個用戶應該只能排隊一次,

為了避免用戶重復排隊的情況,可以為每個用戶在Redis中設定一個自增值,每次排隊的時候加1,如果大于1,說明重復排隊了,那么直接拋出例外,告訴用戶重復排隊了,

//SeckillOrderServiceImpl
@Override
public boolean add(Long id, String time, String username) {
    Long increment = redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_QUEUE_COUNT).increment(username, 1);
    if (increment>1) {  //記錄指定hashkey的增量,大于1說明排隊次數超過1次,重復排隊
        throw new RuntimeException("重復排隊");
    }
	…………
}

這段代碼中,添加了對用戶重復排隊的判斷,先自增1,再進行判斷,這里的key設定的是username,因為一個用戶只能下單一件商品,如果去下單其它商品,同樣也是重復排隊,

測驗了一下,是成功的,但是有一個問題:如果用戶在這里排隊未成功,該怎么清理排隊資訊呢?這個下一步就會說,接著往下看👇

并發超賣問題解決

現在的代碼看似很完美,但是漏洞百出,比如就存在并發超賣的問題,為什么這么說,看代碼說話:

這個是多執行緒下單的方法,流程是查庫存——>下單——>減庫存,假如現在有件商品還剩1件,正好有多個執行緒同時走到了查詢庫存這一步,結果查出來都是一件,然后這三個執行緒就可以往下接著走,最后三個執行緒都成功下單了,不就多賣了兩件嘛,所以這段代碼還存在問題,那怎么解決呢?可不可以采用加鎖的方法,不可以,因為如果是在集群環境下,一臺機器上多個執行緒走到了同一步確實可以鎖住防止超賣,但是不同機器上的執行緒走到了同一部就鎖不住了,

所以可以采用Redis佇列的方式去解決,

給每個sku創建一個佇列,比如id為4399的商品數量為4,那么就在4399的佇列里放入4件商品,然后每次查詢就從佇列里去取,假如現在有五個執行緒去查庫存,因為只有4件商品,所以5個執行緒只有4個執行緒能夠查詢出庫存,因為Redis是單執行緒的,所以不會出現多個執行緒同時訪問資料出錯的情況,這樣就可以避免并發超賣的問題,

之前在SeckillGoodsPushTask中只是將商品存入Redis中,現在再加一步,為每個sku都創建一個佇列并存入庫存數量的資料到佇列中,

//定時將秒殺商品加載到redis中
@Scheduled(cron = "0/5 * * * * ?")
public void loadGoodsPushRedis() {
		…………
        for (SeckillGoods seckillGood : seckillGoods) {
            boundHashOperations.put(seckillGood.getId(),seckillGood);   //把商品存入到redis
            redisTemplate.boundListOps(SystemConstants.SEC_KILL_GOODS_COUNT_LIST + seckillGood.getId())
                    .leftPushAll(getGoodsNumber(seckillGood.getNum()));	//存到Redis佇列
        }
    }
}

//獲取秒殺商品數量的陣列
public Byte[] getGoodsNumber(int num) {
    Byte[] arr = new Byte[num];
    for (int i = 0; i < num; i++) {
        arr[i] = '0';
    }
    return arr;
}

佇列的內容就是商品數量的Byte,視頻中用的是商品id,但是商品id是Long型的,Byte比Long要省空間,而且放什么無所謂關鍵是放幾個,所以我就放了對應數量的Byte進去,

接下來就該在下單之前獲取庫存的資訊:

@Async
public void createOrder() {
	…………
    //從秒殺商品佇列中獲取資料,如果獲取不到則說明已經賣完了,清除掉排隊資訊
    Object o = redisTemplate.boundListOps(SystemConstants.SEC_KILL_GOODS_COUNT_LIST + seckillGoods.getId())
            .rightPop();
    if (o == null) {
        redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_QUEUE_COUNT).delete(seckillStatus.getUsername());  //清除排隊佇列
        redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_STATUS_KEY).delete(seckillStatus.getUsername());   //排隊狀態佇列
        return;
    }
    //創建秒殺訂單
    …………
}

如果商品庫存不足,那么應該清除掉排隊的資訊,否則用戶該商品下不了單還不能下單其它商品,這里將排隊的佇列以及查詢狀態的佇列清除了,

同步庫存不精準問題

解決了并發超賣的問題之后,還有一個庫存數量不精準的問題,這個問題出現的原因和超賣問題類似,假如現在同時有兩個執行緒下單完成了開始遞減庫存,A執行緒查詢出庫存有3個,B執行緒也查詢出庫存有3個,然后它們同時遞減,都是2個,寫到了資料庫中,其實此時庫存應該還剩一個,

解決的辦法也很簡單,因為現在是呼叫**seckillGoods.getStockCount()**查詢出的庫存,那我們就不用這個查詢,直接用上一節中的佇列,佇列中剩余多少就說明現在的庫存是多少,絕對準確,

@Async
public void createOrder() {
	…………
	//減庫存,如果庫存沒了就從redis中洗掉,并將庫存資料寫到MySQL中
    //seckillGoods.setStockCount(seckillGoods.getStockCount()-1);
    Long size = redisTemplate.boundListOps(SystemConstants.SEC_KILL_GOODS_COUNT_LIST + seckillGoods.getId()).size();//獲取庫存
    //if (seckillGoods.getStockCount() <= 0) {
    seckillGoods.setNum(size.intValue());
    if (size <= 0) {
        seckillGoodsBoundHashOps.delete(seckillStatus.getGoodsId());
        seckillGoodsMapper.updateByPrimaryKeySelective(seckillGoods);
    } else {
        seckillGoodsBoundHashOps.put(seckillStatus.getGoodsId(),seckillGoods);
    }
    //創建秒殺訂單
    …………
}    

秒殺支付

改造二維碼創建及支付結果通知方法

秒殺支付的流程和之前做的類似,只不過現在秒殺訂單的支付狀態發送到Queue2中,普通訂單還是發送到queue1中,但是我們怎么知道該將訂單的支付狀態發送給queue1還是queue2呢?如果微信服務器可以將MQ佇列的exchange和routingKey回傳給我們就好了,這樣我們就可以動態地指定要發送的MQ了,

從微信支付的官方檔案中我們可以知道在創建二維碼和接收支付結果的引數中都有一個attach引數

這個是自定義的資料,也就是說我們在創建二維碼的時候發送給微信服務器什么,回傳支付結果的時候就會回傳給我們什么,所以在創建二維碼的時候由前端將指定的exchange和routingKey發送給后端,然后再添加到attach引數中,就可以實作將不同的訂單動態地發送到指定的佇列了,

普通訂單:exchange:exchange.order routingKey:routing.order

秒殺訂單:exchange:exchange.seckill_order routingKey:routing.seckill_order

由于之前寫的createNative方法是接收一個order物件,所以在Order里面添加兩個欄位:

private String exchange;    //mq交換機的名稱
private String routingKey; 	//mq的路由鍵

修改之前**createNative()**的代碼,添加attach引數,

@Override
public Map<String, String> createNative(Order order) {
		…………
        //獲取exchange和routingKey,封裝程map集合,添加到attach引數中
        String exchange = order.getExchange();
        String routingKey = order.getRoutingKey();
        Map<String,String> attachMap = new HashMap<>(2);
        attachMap.put("exchange",exchange);
        attachMap.put("routingKey",routingKey);
        String attach = JSON.toJSONString(attachMap);
        map.put("attach",attach);
		…………
}

然后再修改**WeChatPayController.notifyUrl()**方法,從服務器回傳的Map集合中獲取attach,并從attach中獲取exchange和routingKey,

@RequestMapping("/notify/url")
public String notifyUrl(HttpServletRequest request) throws Exception {
	…………
    Map<String, String> xmlMap = WXPayUtil.xmlToMap(xmlString);
    String attach = xmlMap.get("attach");
    Map<String, String> attachMap = JSONObject.parseObject(attach, Map.class);

    //將java物件轉換成amqp訊息發送出去,呼叫的是send方法
    //rabbitTemplate.convertAndSend("exchange.order","routing.order", xmlString);
    rabbitTemplate.convertAndSend(attachMap.get("exchange"),attachMap.get("routingKey"), xmlString);
	…………
}

監聽秒殺

前面已經將訊息發送到訊息佇列中了現在就可以去監聽訊息佇列了,

從流程圖中可以看到,在寫監聽的方法之前,需要有兩個方法:改訂單狀態和洗掉訂單,

SeckillOrderServiceImpl.updatePayStatus

public void updatePayStatus(String username, String transactionId, String endTime) {
    //從Redis中將訂單資訊查詢出來
    SeckillOrder order = (SeckillOrder) redisTemplate
        .boundHashOps(SystemConstants.SEC_KILL_ORDER_KEY)
        .get(username);
    if (order != null) {
        try {
            order.setStatus("1");
            order.setTransactionId(transactionId);
            SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMddHHmmss");
            order.setPayTime(simpleDateFormat.parse(endTime));
            seckillOrderMapper.insertSelective(order);  //將訂單資訊存到mysql中
			
            //洗掉redis中的訂單資訊
            redisTemplate.boundHashOps(SystemConstants.SEC_KILL_ORDER_KEY).delete(username);    

            //洗掉用戶的排隊資訊
            redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_QUEUE_COUNT).delete(username);  //清除排隊佇列
            redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_STATUS_KEY).delete(username);   //排隊狀態佇列
        } catch (ParseException e) {
            e.printStackTrace();
        }
    }
}

首先將訂單資訊從Redis中查詢出來,將訂單狀態改為已支付,然后將交易流水號和支付時間補充完整存入MySQL,這時候交易已經完成了,可以將訂單資訊從Redis中洗掉,并將用戶的排隊資訊也一并洗掉,

SeckillOrderServiceImpl.deleteOrder

public void deleteOrder(String username) {
    //洗掉Redis中的訂單
    redisTemplate.boundHashOps(SystemConstants.SEC_KILL_ORDER_KEY).delete(username);

    //洗掉用戶的排隊資訊
    redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_QUEUE_COUNT).delete(username);  //清除排隊佇列
    redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_STATUS_KEY).delete(username);   //排隊狀態佇列

    //查詢出秒殺的狀態資訊
    SeckillStatus seckillStatus = (SeckillStatus) redisTemplate.boundHashOps(SystemConstants.SEC_KILL_USER_STATUS_KEY)
            .get(username);

    //回滾庫存
    SeckillGoods seckillGoods = (SeckillGoods) redisTemplate
            .boundHashOps(SystemConstants.SEC_KILL_GOODS_PREFIX + seckillStatus.getTime())
            .get(seckillStatus.getGoodsId());
    if (seckillGoods == null) {
        seckillGoodsMapper.selectByPrimaryKey(seckillGoods.getId());
        seckillGoods.setStockCount(seckillGoods.getStockCount()+1);
        seckillGoodsMapper.updateByPrimaryKeySelective(seckillGoods);
    } else {
        seckillGoods.setStockCount(seckillGoods.getStockCount()+1);
    }
    redisTemplate
            .boundHashOps(SystemConstants.SEC_KILL_GOODS_PREFIX + seckillStatus.getTime())
            .put(seckillGoods.getId(),seckillGoods);

    //將商品放入佇列
    redisTemplate.boundListOps(SystemConstants.SEC_KILL_GOODS_COUNT_LIST + seckillGoods.getId())
            .leftPush("0");
}

支付失敗了,應該將訂單洗掉掉,首先將Redis中的訂單洗掉,然后洗掉用戶的排隊資訊,接著回滾庫存,如果Redis中沒有則說明已經賣完了,就從MySQL中查詢出來然后將商品數量加1再存入MySQL;如果Redis中有資料就將Redis中的商品數量加1即可,上面講防止并發超賣的時候不是為每個商品都在Redis佇列中存放了一下么,所以最后將商品放回到佇列中,

SeckillMessageListener

@Component
@RabbitListener(queues = "queue.seckillorder")
public class SeckillMessageListener {

    @Autowired
    private SeckillOrderService seckillOrderService;

    //https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=9_7&index=8
    @RabbitHandler
    public void getMessage(String message) {
        try {
            Map<String, String> resultMap = JSON.parseObject(message,Map.class);
            String returnCode = resultMap.get("return_code");   //狀態碼
            if ("SUCCESS".equals(returnCode)) {
                String resultCode = resultMap.get("result_code");   //業務結果
                String attach = resultMap.get("attach");
                Map<String,String> attachMap = JSON.parseObject(attach,Map.class);
                if ("SUCCESS".equals(resultCode)) {
                    //改訂單狀態
                    seckillOrderService.updatePayStatus(attachMap.get("username"),
                            resultMap.get("transaction_id"),resultMap.get("time_end"));
                } else {
                    //洗掉訂單
                    seckillOrderService.deleteOrder(attachMap.get("username"));
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

這個方法使用來監聽秒殺佇列的訊息的,exchange和queue需要我們手動地在RabbitMQ的網頁中創建并進行系結

在該方法中,首先去讀取狀態碼和業務結果,如果都為“SUCCESS”的話則說明訂單支付成功,修改訂單的狀態,反之訂單支付失敗,洗掉訂單,

總結

文章鴿了快一個月了,終于補上了,主要是上篇文章寫完后就在做個小東西,然后就是國慶節放假,在家待著有點懶,回校后又在參加電賽,沒時間,所以一路鴿到現在,

這篇文章主要是將之前的秒殺流程進行一個完善,實作了防止秒殺重復排隊,解決并發超賣的問題,并解決了同步庫存不精準的問題,最后實作了秒殺支付,

碼字不易,可以的話,給我來個點贊收藏關注

如果你喜歡我的文章,歡迎關注微信公眾號 R o b o d

代碼:https://github.com/RobodLee/changgou

本文已收錄至我的Github倉庫DayDayUP:github.com/RobodLee/DayDayUP,歡迎Star

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/180540.html

標籤:其他

上一篇:SpringMVC概念和第一個程式

下一篇:攤牌了,我要手寫一個RPC

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more