架構(gòu)
-
mybatis日志功能是如何設(shè)計的？
我們在使用mybatis時，如果出現(xiàn)sql問題，一般會把mybatis配置文件中的logging.level參數(shù)改成debug，這樣就能在日志中看到某個mapper最終執(zhí)行sql、入?yún)⒑陀绊憯?shù)據(jù)行數(shù)。我們拿到sql和入?yún)?，手動拼接成完整的sql，然后將該sql在數(shù)據(jù)庫中執(zhí)行一下，就基本能定位到問題原因。mybatis的日志功能使用起來還是非常方便的，大家有沒有想過它是如何設(shè)計的呢？
-
對比5種分布式事務方案，還是寵幸了阿里的Seata（原理 + 實戰(zhàn)）
本來不知道寫點啥，正好手頭有個新項目試著用阿里的Seata中間件做分布式事務，那就做一個實踐分享吧！
-
這次我讓你徹底弄懂RESTful
RESTful想必大家都耳熟能詳，但為什么要有RESTful？RESTful 到底是什么意思？為什么稱之為 RESTful 架構(gòu)？我不用 RESTful 不行嗎？什么樣才叫真正的 RESTful？
-
8場5勝，微服務 VS 單體架構(gòu)
越來越多的組織開始放棄單體應用，逐步轉(zhuǎn)向微服務的架構(gòu)模式–將業(yè)務流程分為多個獨立的服務。微服務架構(gòu)，就是將各個流程按照業(yè)務拆分為獨立的服務。在上面的示例中，機票預訂服務可以被拆分為機票預訂，付款和確認，拆分后的微服務可以通過接口相互通信。那么，微服務與單體應用，究竟有什么不同？
-
CTO怒了：“如果中臺不省錢，我建什么中臺??！”
小M之前一直從事企業(yè)信息化改革工作，幫助過幾家公司實現(xiàn)了云化，積累了一定的項目經(jīng)驗。L總所在的企業(yè)，信息系統(tǒng)架構(gòu)老舊，經(jīng)過10幾年的發(fā)展，形成了幾十個大“煙囪”系統(tǒng)，數(shù)據(jù)的互聯(lián)互通是難題，嚴重制約了業(yè)務的發(fā)展，讓集團大領(lǐng)導非常不滿。于是L總聘用了小M，先是任命他為“基礎(chǔ)資源整合”負責人，具體干什么呢？就是建云平臺，把集團各部門的服務器、網(wǎng)絡(luò)資源統(tǒng)一管理，提高硬件使用率，降低成本。
-
終于有人把前臺、中臺、后臺都講明白了
大數(shù)據(jù)DT我們來看一下阿里巴巴對前臺、中臺和后臺職責的定位。前臺主要面向客戶以及終端銷售者，實現(xiàn)營銷推廣以及交易轉(zhuǎn)換。中臺主要面向運營人員，完成運營支撐。后臺主要面向后臺管理人員，實現(xiàn)流程審核、內(nèi)部管理以及后勤支撐，比如采購、人力、財務和OA等系統(tǒng)。企業(yè)級能力往往是前臺、中臺、后...
-
如何設(shè)計訂單系統(tǒng)？
本文主要講述了在傳統(tǒng)電商企業(yè)中，訂單系統(tǒng)應承載的角色，就訂單系統(tǒng)所包含的主要功能模塊梳理了設(shè)計思路，并對訂單系統(tǒng)未來的發(fā)展做了一些思考。
-
從無到有，支付路由系統(tǒng)升級打怪之路（原創(chuàng)）
提到路由，不免會想到網(wǎng)絡(luò)通信過程中起到數(shù)據(jù)包轉(zhuǎn)發(fā)的路由器。而我們今天講到支付路由系統(tǒng)，也是起到類似的作用。
-
優(yōu)秀！一鼓作氣學會“一致性哈?！保涂窟@18張圖了
當架構(gòu)師大劉看到實習生小李提交的記賬流水亂序的問題的時候，他知道沒錯了：這一次，大劉又要用一致性哈希這個老伙計來解決這個問題了。嗯，一致性哈希，分布式架構(gòu)師必備良藥，讓我們一起來嘗嘗它。
-
萬字長文，理解Elasticsearch和面試總結(jié)
一文了解Elasticsearch集群部署與性能優(yōu)化。
-
面向領(lǐng)域的微服務架構(gòu)
近來，一些關(guān)于面向服務架構(gòu)的話題，特別是針對微服務架構(gòu)的弊端這個話題上進行了大量的討論。雖然在幾年前，微服務架構(gòu)受到很多人的青睞，因為它們提供了許多好處，如獨立部署的靈活性、明確的所有權(quán)、系統(tǒng)穩(wěn)定性的改善以及更好的分離問題等優(yōu)點。但是不久，就開始有人吐槽微服務會大幅增加系統(tǒng)復雜性，有時甚至連一些簡單的功能都難以構(gòu)建。
-
高德全鏈路壓測：語料智能化演進之路
全鏈路壓測作為線上服務穩(wěn)定性保障的重要手段，對高德來說也是非常重要的。高德全鏈路壓測平臺TestPG從無到有，在經(jīng)歷過常態(tài)化壓測后，已基本可以保障高德的所有全鏈路壓測和日常壓測，達到了平臺初期快速、準確壓測和全鏈路壓測的目標。而語料生產(chǎn)(流量處理)作為全鏈路壓測的重要環(huán)節(jié)，本文將對此做重點介紹。
-
拿下計網(wǎng)協(xié)議后，我就是公園里最靚的仔
下面我們就要對不同的協(xié)議層進行分類介紹了，我們還是采用自上而下的方式來介紹，這種介紹對讀者來說更容易接納，吸收程度更好。
-
一個架構(gòu)師的緩存修煉之路
一位七牛的資深架構(gòu)師曾經(jīng)說過這樣一句話：Nginx+業(yè)務邏輯層+數(shù)據(jù)庫+緩存層+消息隊列，這種模型幾乎能適配絕大部分的業(yè)務場景。這么多年過去了，這句話或深或淺地影響了我的技術(shù)選擇，以至于后來我花了很多時間去重點學習緩存相關(guān)的技術(shù)。我在10年前開始使用緩存，從本地緩存、到分布式緩存、再到多級緩存，踩過很多坑。下面我結(jié)合自己使用緩存的歷程，談談我對緩存的認識。
-
刨根問底，Kafka消息中間件到底會不會丟消息
大型互聯(lián)網(wǎng)公司一般都會要求消息傳遞最大限度的不丟失，比如用戶服務給代金券服務發(fā)送一個消息，如果消息丟失會造成用戶未收到應得的代金券，最終用戶會投訴。為避免上面類似情況的發(fā)生，除了做好補償措施，更應該在系設(shè)計的時候充分考慮各種異常，設(shè)計一個穩(wěn)定、高可用的消息系統(tǒng)。
-
還用System.out.println("")；太 Low了!
小張，開發(fā)一個大型系統(tǒng)，寫了一個統(tǒng)一的接口層；日志門面（日志的一個抽象層）；logging-abstract.jar；給項目中導入具體的日志實現(xiàn)就行了；我們之前的日志框架都是實現(xiàn)的抽象層……
-
要我說，多線程事務它必須就是個偽命題！
分布式事務你應該是知道的。但是這個多線程事務...... 沒事，我慢慢給你說。
-
到底什么是Cortex、ARMv8、arm架構(gòu)、ARM指令集、soc？一文幫你梳理基礎(chǔ)概念
有粉絲問我到底什么是ARM，搞不清楚Cortex、arm內(nèi)核、arm架構(gòu)、ARM指令集、soc這些概念都是什么關(guān)系，本文給大家整理一下關(guān)于ARM相關(guān)的一些概念。
-
面對千萬級、億級流量怎么處理？
面對超高的并發(fā)，首先硬件層面機器要能扛得住，其次架構(gòu)設(shè)計做好微服務的拆分，代碼層面各種緩存、削峰、解耦等等問題要處理好，數(shù)據(jù)庫層面做好讀寫分離、分庫分表，穩(wěn)定性方面要保證有監(jiān)控，熔斷限流降級該有的必須要有，發(fā)生問題能及時發(fā)現(xiàn)處理。這樣從整個系統(tǒng)設(shè)計方面就會有一個初步的概念。
-
架構(gòu)設(shè)計：業(yè)務邏輯和技術(shù)分離
關(guān)于架構(gòu)這個概念很難給出一個明確的定義，也沒有一個標準的定義。硬是要給一個概述，我認為架構(gòu)就是對系統(tǒng)中的實體以及實體之間的關(guān)系所進行的抽象描述。
