1 def loadTestsFromTestCase(self, testCaseClass) #看名稱分析：從TestCase找測試集--那麼就是把我們的def用例加載到testSuit裏面
 2 def loadTestsFromModule(self, module, *args, pattern=None, **kws) #看名稱分析：從模塊裏面找測試集，那麼 模塊>類>test_方法>添加到testSuit裏面
 3 def loadTestsFromName(self, name, module=None)  #看名稱分析： 接收到name直接添加到testSuit裏面
 4 def loadTestsFromNames(self, names, module=None) #看名稱分析：接受到的是一個包含測試test_方法的列表
 5 def getTestCaseNames(self, testCaseClass) # 看名稱分析：  取出一個包含test_方法的列表
 6 def discover(self, start_dir, pattern='test*.py', top_level_dir=None) ## 看名稱分析：發現--找test_方法
 7 def _get_directory_containing_module(self, module_name) #獲取目錄包含的模塊
 8 def _get_name_from_path(self, path)  #從路徑從找名稱
 9 def _get_module_from_name(self, name)  #從名稱找模塊
10 def _match_path(self, path, full_path, pattern)   #正則匹配路徑--參數包含pattern 那估計是匹配我們測試腳本格式的
11 def _find_tests(self, start_dir, pattern, namespace=False)  #找測試集合
12 def _find_test_path(self, full_path, pattern, namespace=False)  #找測試集合的路徑

View Code

 1 那就是1234
 2 一個discover,getTest,_match_path
 3 二個find
 4 三個_get
 5 四個loadTests
 6 
 7 discover  邏輯
 8 >
 9 _find_tests【兩個處理邏輯  一個是本次傳的目錄和上次傳的一樣或不一樣，】
10 【一樣：直接從我們傳的目錄下面繼續去找testcaose---】
11 【不一樣：會從我們傳的目錄下面去執行os.path.listdir找到所有的子文件列表paths(文件))，然後遍歷得到單獨的path做 start_dir+path拼接】
12 >
13 ①—get_name_from_path【傳入start_dir,判斷當前傳入的目錄是否為上次傳入的頂級目錄返回".",不一樣可能有點繞-並返回一個值這個值有四種情況 . test  ...test dir.tests--正常應該是返回test文件名
14 ②_find_test_path(self, full_path, pattern, namespace=False)
15 【執行這個從路徑中找test，那麼很明顯 一樣：傳目錄路徑   不一樣傳文件路徑  】
16 _find_test_path

View Code

 1 class TestLoader(object):
 2     """
 3     This class is responsible for loading tests according to various criteria
 4     and returning them wrapped in a TestSuite
 5     """
 6     testMethodPrefix = 'test'
 7     sortTestMethodsUsing = staticmethod(util.three_way_cmp)
 8     suiteClass = suite.TestSuite
 9     _top_level_dir = None
10 
11     def __init__(self):
12         super(TestLoader, self).__init__()
13         self.errors = []
14         # Tracks packages which we have called into via load_tests, to
15         # avoid infinite re-entrancy.
16         self._loading_packages = set()  #這裏創建了一個空的self._loading_packages={}無序且不重複的元素集合

View Code 1.discover方法：unittest.defaultTestLoader a.定義了三個布爾值屬性 is_not_importable==True則是不能導入，is_namespace ，set_implicit_top b.對頂層目錄做了處理–當服務首次啟動 執行unittest.defaultTestLoader.discover(“文件目錄A”,pattern,top_level_dir=None):self._top_level_dir = top_level_dir = start_dir 這三個相等。 再次執行unittest.defaultTestLoader.discover(“文件目錄B”,pattern,top_level_dir=None): top_level_dir=self._top_level_dir【也就是他會默認上次start_dir 為頂層目錄】– 無論是首次還是複次–上面的操作完成之後 self._top_level_dir = top_level_dir 仍然繼續執行了一句這個—也就是說 self._top_level_dir == top_level_dir 始終一樣 c.針對頂層目錄不是一個目錄文件做了一系列的處理如果你傳的目錄是一個可導入的模塊-他在這個異常處理中.會重新自導入這個模塊。並開始追尋他的絕對路徑,判斷其模塊的可用性，然後執行_find_tests()尋找用例 d.如果是一個目錄就直接開始執行_find_tests()尋找用例 e.所以他這裏分兩種情況可以找到用例 第一種:傳的目錄 第二種:傳入的可導入模塊-這種情況self._top_level_dir 最終也是一個絕對路徑

  1 def discover(self, start_dir, pattern='test*.py', top_level_dir=None):  #一般我們top_level_dir傳的都None
  2     set_implicit_top = False   #是否存在頂層目錄
  3     if top_level_dir is None and self._top_level_dir is not None:
  4         # make top_level_dir optional if called from load_tests in a package
  5         top_level_dir = self._top_level_dir  #複次走這裏
  6     elif top_level_dir is None:  #初次走這裏
  7         set_implicit_top = True
  8         top_level_dir = start_dir
  9     #上面這一串花里胡哨的東西就是處理頂層目錄-如果是第一次啟動服務-
 10     #就走elif-top_level_dir==我們下面傳的值--之後--self._top_level_dir就不為空了，
 11     #但是top_level_dir  頂部是處理==None所以會走if=True
 12     top_level_dir = os.path.abspath(top_level_dir)#轉絕對路徑
 13     if not top_level_dir in sys.path:
 14         #這裡是防止重複將top_level_dir加入執行目錄--BUT如果我第一次傳的start_dir=a,第二次傳的start_dir=b
 15         #分析一下--第一次就是把a加入到了執行目錄---下面self._top_level_dir=a 二次(複次)傳b的時候,會出現top_level_dir=a---並沒有判斷b是否在執行目錄
 16         #這裏加一波問號？？？？？？？？？？？？？？？？？？？？？
 17         #但是一般情況 我們目錄就只有一個--所以這裏--先放着。。。先看後面再來看這裏
 18         # all test modules must be importable from the top level directory
 19         # should we *unconditionally* put the start directory in first
 20         # in sys.path to minimise likelihood of conflicts between installed
 21         # modules and development versions?
 22         sys.path.insert(0, top_level_dir)
 23     self._top_level_dir = top_level_dir
 24     #如果top_level_dir我們傳的目錄不在可執行目錄--則臨時添加進去
 25     is_not_importable = False  #是否  不能導入
 26     is_namespace = False    #is_namespace那麼這個字段的意思就是是否可以找到傳入的路徑
 27     tests = []
 28     if os.path.isdir(os.path.abspath(start_dir)):  #判斷我們傳的是否為一個目錄--實際上這裏直接用top_level_dir不香嗎--
 29         start_dir = os.path.abspath(start_dir)
 30         # 之前把top_level_dir = start_dir
 31         # 然後top_level_dir = os.path.abspath(top_level_dir)
 32         #現在start_dir = os.path.abspath(start_dir)
 33         #為什麼不   直接用top_level_dir？  小朋友你是否有許多問號
 34         # 問題出在上面--複次的時候--並沒有走 top_level_dir = start_dir 而是走的 top_level_dir = self._top_level_dir ，
 35         #所以如果我們上次傳的路徑如果和這次不一樣--那麼top_level_dir是不等於start_dir--而start_dir才是我們傳的--
 36         if start_dir != top_level_dir:  #所以這裏相當於判斷前後傳的路徑是否一樣--一般來說我們的start_dir都是等於top_level_dir的
 37             is_not_importable = not os.path.isfile(os.path.join(start_dir, '__init__.py'))#如果是一個文件返回false
 38             #如果不一樣--則判斷我們當前傳入的start_dir/__init__.py是不是一個正確的文件路徑..os.path.isfile() 返回布爾值
 39     else: #如果我們傳入的不是一個目錄,就開始一堆花里胡哨的報錯東西了。。暫時不用管
 40         # support for discovery from dotted module names
 41         try:
 42             __import__(start_dir)
 43             #這裏就很有意思了---__impor__("PyFiles.Besettest")那就是導入PyFiles
 44             #那麼也就是說這個97.33的概率會報錯--也就是說你如果目錄錯了--下面的else基本不會走。。。除非你很神奇的填的路徑右側是一個可導入的模塊
 45         except ImportError:
 46             is_not_importable = True   #如果導入不鳥--就is_not_importable設置為true  在這裏我清楚了這個字段的含義--不能導入=true
 47         else:#那麼這裏假設導入成功之後
 48             the_module = sys.modules[start_dir]  #這裡是如果我們導入成功--就走這裏-取出start_dir導入的賦值給the_module
 49             top_part = start_dir.split('.')[0]    #這裡是將我們導入的模塊名稱取出來
 50             try:
 51                 start_dir = os.path.abspath( #打印導入模塊所在目錄的絕對路徑
 52                    os.path.dirname((the_module.__file__)))
 53             except AttributeError:     #這裡是如果導入模塊成功了---但是尼瑪打印導入模塊的絕對路徑又報錯--不想看了+2
 54                 # look for namespace packages
 55                 try:  #然後有開始進行模塊導入檢查---日了狗了。。。。。
 56                     #  fuck----想直接關機了+1，這裏估計是想找到為什麼不能導入的原因。。大神的思路就是完美，如果是我就拋出一個目錄不對就完事
 57                     #這一塊的學習 文檔 Python標準模塊--import
 58                     spec = the_module.__spec__
 59                     #將導入成功的模塊的規格說明賦值給spec--
 60                     #打印出來就是ModuleSpec(name='besettest.interface', loader=<_frozen_importlib_external.SourceFileLoader object at 0x0000000003D6E780>, origin='E:\\PyFiles\\Besettest\\besettest\\interface\\__init__.py', submodule_search_locations=['E:\\PyFiles\\Besettest\\besettest\\interface'])
 61                     #這麼一串東西--也沒用過。。。。大概就是模塊名稱、路徑、導入的模塊對象吧
 62                     #origin 加載模塊的位置--
 63                     #loader_state模塊特定數據的容器
 64                 except AttributeError:  #如果模塊的規格說明取不出來。。。。。。。
 65                     spec = None   #我查閱了一下。。。的確存在部分模塊規格說明為None的--所以還得繼續往下看
 66 
 67                 if spec and spec.loader is None:   #如果存在規格說明 且 數據容器為None。
 68                     if spec.submodule_search_locations is not None: 
 69                         #這是個什麼玩意呢--模塊 搜索 位置s(列表)。。。
 70                         is_namespace = True    #如果spec.submodule_search_locations不為none -----
 71                         # 2.5級英文翻譯 就是模塊的路徑 如果模塊路徑不為空is_namespace可以找到---is_namespace那麼這個字段的意思就是存在命名空間。。就是可以找到這個模塊
 72                         for path in the_module.__path__:   #這裏我研究懷疑是故意提升逼格。。the_module.__path__==spec.submodule_search_locations
 73                             if (not set_implicit_top and     #首次set_implicit_top==True  複次set_implicit_top==Fase
 74                                 not path.startswith(top_level_dir)):
 75                                 continue
 76                                 #這裏讓我稍微有點疑惑。。為什麼要判斷是首次還是複次--我猜是判斷the_module.__path__列表裡面有幾個某塊的路徑
 77                                 #如果是首次直接下一步--如果是複次會有多個路徑。但是如果是複次top_level_dir這個路徑又是上次的。。。日
 78                                 #他的作用是找到導入模塊的路徑-知道這個就行。。。
 79                             self._top_level_dir = \
 80                                 (path.split(the_module.__name__
 81                                      .replace(".", os.path.sep))[0])   #取出導入模塊的上級目錄絕對路徑。。。
 82                             #the_module.__name__.replace(".", os.path.sep) 這一串我看來是沒有必要的。。因為  the_module.__name__既然取到了模塊名稱那他肯定是一個字符串
 83                             tests.extend(self._find_tests(path,     #然後調用_find_tests 尋找測試。加入tests列表--這個有點熟悉的味道---
 84                                                           pattern,  #我覺得基本不會走這裏去找---腳本路徑一般都會填對  填錯了，都不知道執行到哪裡去了。。。
 85                                                           namespace=True))
 86                 elif the_module.__name__ in sys.builtin_module_names:
 87                     #判斷 sys.builtin_module_names返回一個列表，包含所有已經編譯到Python解釋器里的模塊的名字 和sys.models是一個字典
 88                     #就是沒法導入報錯
 89                     # builtin module
 90                     raise TypeError('Can not use builtin modules '
 91                                     'as dotted module names') from None
 92                 else:  #沒發現這個模塊
 93                     raise TypeError(
 94                         'don\'t know how to discover from {!r}'
 95                         .format(the_module)) from None
 96 
 97             if set_implicit_top:     #如果是首次。。。。
 98                 if not is_namespace:  #is_namespace默認的是false-且可以找到模塊相關規格
 99                     self._top_level_dir = \
100                        self._get_directory_containing_module(top_part)  #interface.testFiles   interface假設這個是導入的 -self._top_level_dir 是一個目錄的絕對路徑
101                     #top_part導入的模塊名稱-----
102                     sys.path.remove(top_level_dir)    #只知道是從系統路徑移除--但是不知道為什麼移除。。。。
103                 else:
104                     sys.path.remove(top_level_dir)   #
105 
106     if is_not_importable:   #如果我們傳的文件不能導入---就直接拋出異常
107         raise ImportError('Start directory is not importable: %r' % start_dir)
108 
109     if not is_namespace:  #is_namespace默認的是false--這裏就是可以找到模塊。。。。
110         tests = list(self._find_tests(start_dir, pattern))
111     return self.suiteClass(tests)

View Code 2._find_tests()–尋找testCase並生成測試套件tests=[]

 1 def _find_tests(self, start_dir, pattern, namespace=False):   #注意這裏如果我們傳的不是腳本目錄而是一個可導入的模塊namespace是等於True的
 2     """Used by discovery. Yields test suites it loads."""
 3     # Handle the __init__ in this package
 4     name = self._get_name_from_path(start_dir)   #返回一個name   name存在三種返回情況  "."-當本次和上次傳入的start_dir一致     不一致  "文件名"    "...文件名"
 5      #get_name_from_path的邏輯在這裏就很清晰了 
 6           
 7     # name is '.' when start_dir == top_level_dir (and top_level_dir is by
 8     # definition not a package).
 9     if name != '.' and name not in self._loading_packages:  
10     #當name最少有一個且也不再self._loading_packages.【self._loading_packages初始化的時候建的空集合】 走下面這個
11         # name is in self._loading_packages while we have called into
12         # loadTestsFromModule with name.
13         tests, should_recurse = self._find_test_path(      #然後這裏start_dir是我們傳的模塊--他就去找。。這裏就恢復到了傳測試目錄的邏輯了
14             start_dir, pattern, namespace)
15         if tests is not None:
16             yield tests
17         if not should_recurse:
18             # Either an error occurred, or load_tests was used by the
19             # package.
20             return
21     # Handle the contents.
22     paths = sorted(os.listdir(start_dir))  #那就從這裏開始--當我們穿的目錄和上次一樣-他會找到目錄下所有的文件然後排序--我們的用例執行順序就是從這裏開始搞了。。
23     for path in paths:       #遍歷我們傳的目錄下的所有文件
24         full_path = os.path.join(start_dir, path)     將我們傳入的目錄和目錄下的py文件拼接的完整路徑
25         tests, should_recurse = self._find_test_path(    #把我們文件路徑和我們的文件格式傳入_find_test_path這個方法--
26             full_path, pattern, namespace)
27         如果當前傳的是一個目錄-會返回should_recurse=True--這個英文直譯是應該_遞歸--下面yield from 就是執行遞歸的操作
28         if tests is not None:
29             yield tests
30         if should_recurse:  #這句是判斷他是不是一個目錄
31             # we found a package that didn't use load_tests.
32             name = self._get_name_from_path(full_path)
33             self._loading_packages.add(name)
34             try:
35                 yield from self._find_tests(full_path, pattern, namespace)
36             finally:
37                 self._loading_packages.discard(name)

View Code yield與yield from

 1 def  a(n):
 2     testList=b(n)
 3     return testList
 4 
 5 def  b(n,m=1):
 6     print("執行第%s次"%m)
 7     for a in range(n):
 8         if not divmod(a,2)[1] and a!=0:
 9             print(a)
10             yield a   #是用yield之後返回的是一個生成器
11             if divmod(a,3)[1]:
12                 m =m+1
13                 yield from b(a,m)  #重新執行b方法
14 
15 print(list(a(7)))
16 
17 執行第1次
18 2
19 執行第2次
20 4
21 執行第3次
22 2
23 執行第4次
24 6
25 [2, 4, 2, 6]

View Code _get_name_from_path 他主要做了：從我們傳的路徑裏面找腳本文件 名。。。如果找到了腳本文件則返迴文件名稱—如果沒找到也就是我們返回一個點 或者 至少一個點（三種情況 . test_case …..test_case 返回name可能存在的三種值） 在_test_find調用這個方法path=start_dir(我們傳的目錄)–這個返回一個點 或者 至少一個點 在 _fin_test_path調用這個方法是傳的我們傳的目錄下的文件路口–返回的name就是文件名

 1 name = self._get_name_from_path(start_dir)    #因為discover我們是支持我們傳目錄或者模塊尋找testcase的，所以這個方法
 2 
 3 def _get_name_from_path(self, path):
 4      #主要正確邏輯三個 比如我們的腳本目錄結構是  E://a/b/     b目錄下面有script.py    和  /c/script.py
 5      #第一次是我們自己傳的目錄--之前在discover他做了一個處理 就是第一次運行時會把我們傳的目錄賦值給頂層目錄---
 6      #第一個邏輯判斷我們傳的是不是  -和頂層一樣---一樣的話===_find_tests方法就直接從目錄下面找腳本-當如如果有目錄也會繼續走--他是在_find_tests_path判斷的--最終也是回到找腳本模塊上
 7      #如果不一樣--那就是找了 找到這個目錄了---那麼就從頂層開始找這個目錄的相對路徑--其實就是找最後那個目錄(必須是一個packge。上面說的目錄都是包)、。。然後返回一個name
 8      #如果還有子目錄  d---那就會返回  c.d
 9     if path == self._top_level_dir:  #首次運行pattern,top_level_dir=None):self._top_level_dir = top_level_dir = start_dir -第二次運行如果目錄沒有變，這裏也是直接返回的
10         return '.'
11         
12         
13     path = _jython_aware_splitext(os.path.normpath(path))  #如果我們當前傳的和上次傳的目錄不一致。。這裏得path我們當前傳的路徑
14     
15     _relpath = os.path.relpath(path, self._top_level_dir)    #從self._top_level_dir開始找path的相對路徑
16     #這裡是從我們傳的path開始找到self._top_level_dir上次傳的相對路徑 
17     #例如： path=path1="E:\\PyFiles\\Besettest\\besettest\\interface\\testFiles"   self._top_level_dir="E:\\PyFiles\\Besettest\\besettest\\interface\\result"
18     #那麼_relpath="..\testFiles"    -暫時還不清楚為什麼要找這個？？？？？？？？？？？？？？？？？？？？？？？？？？
19     assert not os.path.isabs(_relpath), "Path must be within the project"
20     #↑↑斷言 不是絕對路徑-也就是說_relpath是否為相對路徑↑↑↑特么的 這裏肯定是一個相對路徑啊。。。上面都有relpath了。。。丟
21     #↓↓↓↓斷言以..開頭就失敗。。。↓↓↓--這兩處超出理解範圍了。。。。。。
22     assert not _relpath.startswith('..'), "Path must be within the project"
23     
24     name = _relpath.replace(os.path.sep, '.')  #然後這裏又把分隔符替換成.  返回 a.b  當然或許會有異常情況返回.....這是我意淫的
25     return name

View Code self._find_test_path #找測試的路徑 兩個主要邏輯： 傳到full_path 是一個文件 還是一個目錄

 1 def _find_test_path(self, full_path, pattern, namespace=False):  
 2  #_find_tests()調用這個方法 傳了一個我們傳的目錄下的a文件路徑、和需要找的文件pattern-namespace【傳的可能是true 也可能是false】，如果我的目錄是對的-namespace傳的就是false
 3     """Used by discovery.
 4 
 5     Loads tests from a single file, or a directories' __init__.py when
 6     passed the directory.
 7 
 8     Returns a tuple (None_or_tests_from_file, should_recurse).
 9     """
10     basename = os.path.basename(full_path)   #basename==文件名.py後續帶py的統稱文件--不帶後綴的統稱文件名。。。
11     if os.path.isfile(full_path):   #如果我們傳的full_path是一個文件---我們在discover傳的是一個腳本目錄-之前在_test_find是做了一個拼接得到的完整路徑full_path
12         if not VALID_MODULE_NAME.match(basename): #判斷他是不是一個py文件----
13             
14             # valid Python identifiers only
15             return None, False   #如果不是直接返回
16         if not self._match_path(basename, full_path, pattern):  #這裏雖然傳了三個值--但是實際上只有basename，pattern有用--
17          #_match_path調用fnmatch(文件, 我們傳的文件格式或文件)這個需要————from fnmatch import fnmatch他的主要作用是做此模塊的主要作用是文件名稱的匹配
18          #當此次傳入的文件名與我們的文件格式匹配一致self._match_path返回true
19             return None, False    #如果不一樣 就直接回到 _find_test繼續找
20         # if the test file matches, load it
21         name = self._get_name_from_path(full_path)   #然後這裏把文件路徑又傳到 self._get_name_from_path去返迴文件名-這個時候因為我們傳的是腳本目錄-full_path目錄下的文件路徑，所以返回的name 就是文件名
22        
23         #self._top_level_dir是當前文件目錄路徑，path是當前文件路徑--從目錄找文件--直接就是文件名--他返回的name就是文件名   
24         try:
25             module = self._get_module_from_name(name)    #_get_module_from_name  這個方法就是動態導入模塊名--然後返回一個所有導入的模塊的對象 moudel.__file__路徑、moudel.__name__名稱
26         except case.SkipTest as e:   #如果導入不成功 case.SkipTest 實際上case是繼承--Exception--所以把這個理解為Exception就可以了--
27             return _make_skipped_test(name, e, self.suiteClass), False
28         except:
29             error_case, error_message = \
30                 _make_failed_import_test(name, self.suiteClass)   
31             self.errors.append(error_message)
32             return error_case, False
33         else: #module 獲取到值之後走這裏。。
34             mod_file = os.path.abspath(
35                 getattr(module, '__file__', full_path))    #然後這裏取出我們導入模塊的 絕對路徑---如果反射找不到就返回該文件的路徑-其實差別不大-處理一下更嚴謹
36             realpath = _jython_aware_splitext(
37                 os.path.realpath(mod_file))   #os.path.realpath(mod_file)然後又返回真實路徑---然後又去掉路徑的.py，。，，，，，，，，丟
38             fullpath_noext = _jython_aware_splitext(
39                 os.path.realpath(full_path))   #然後full_path 找真實路徑去掉.py
40             if realpath.lower() != fullpath_noext.lower():  #如果動態導入的模塊的目錄路徑 不等於 傳進來(也就是pattern)的目錄路徑--實際上傳進來的路徑肯定是個絕對路徑--因為前面已經轉了好幾次絕對路徑了
41                 module_dir = os.path.dirname(realpath)   #不等於就找動態導入模塊所在的目錄----實際上上面處理的realpath已經是一個目錄了。。但是他防止realpath還是一個.py文件。所以又操作了一次
42                 mod_name = _jython_aware_splitext(    #full_path是文件的路徑.py的，然後這裏又先是basename取出文件(就是把路徑去掉，只留下xxx.py) 然後外面那個方法 把.py去掉--留下文件名
43                     os.path.basename(full_path))
44                 expected_dir = os.path.dirname(full_path)  
45                 #然後找到需要執行腳本所在的目錄。。。。。也就是說正常情況  假設expected_dir="e://a/b"  那麼 mod_file =realpathfullpath_noext="e://a/b/scripy" 
46                 #scripy是一個py文件---上面這個if是說的 正常情況。。。我想不到導入模塊和導入模塊的路徑不相等的情況--不過這個不重要-源碼這樣肯定是有道理的
47                   msg = ("%r module incorrectly imported from %r. Expected "
48                        "%r. Is this module globally installed?")
49                 raise ImportError(
50                     msg % (mod_name, module_dir, expected_dir))
51             return self.loadTestsFromModule(module, pattern=pattern), False   
52             #然後走 從模塊從加載測試s 這個方法---也就是說discover實際上是調用loadTestsFromMould這個方法的。。測試套件也是在這一步處理的
53     elif os.path.isdir(full_path):  #dicover裏面傳腳本目錄是走這裏。。
54         if (not namespace and    #namespace-默認是false   not namespace就是true  
55             not os.path.isfile(os.path.join(full_path, '__init__.py'))): #不是一個包。。-也就是說我們傳的目錄應該是一個包，下面包含__init__.py
56             return None, False
57         
58         load_tests = None  #這個load_tests是啥意思呢？？？？？？？？？？後面繼續看----看了一遍--並且用unittest.main()試了一下-模塊下面是沒有這個屬性的。。只是unittest的初始化文件有這個方法--他也是通過discover找的。。
59         tests = None
60         name = self._get_name_from_path(full_path)   #這裏就是走子目錄的邏輯了
61         #get_name_from_path的邏輯在這裏就很清晰了 
62             #A.如果通過_find_test 調用self._get_name_from_path  是為了判斷兩次start_dir是否一致一致返回.  不一致返回從上次的start_dir1找到本次start_dir12的相對路徑--
63             #這裏又分兩種情況-A1正常情況-start_dir1是start_dir12的上級目錄。。。那麼返回的那麼就是-A.B這樣的了。。因為第一次的A是已經os.path.insert到環境變量了..所以A.B是可以直接用
64                                 #A2不正常情況 就是之前說的 最少返回一個點的...A這種返回---然後問題來了--他為什麼要這麼處理呢--原因是？？？？？？？？？
65                                 #我猜是與腳本同級存在另一個腳本目錄。。。後面驗證這一點。-----這裡在上面補充了--是因為子目錄中還存在腳本所有這麼走邏輯-完美的
66         try:
67             package = self._get_module_from_name(name)   #上面是導入的一個module--這裡是導入一個包-- 返回--
68         except case.SkipTest as e:
69             return _make_skipped_test(name, e, self.suiteClass), False
70         except:
71             error_case, error_message = \
72                 _make_failed_import_test(name, self.suiteClass)
73             self.errors.append(error_message)
74             return error_case, False
75         else:
76             load_tests = getattr(package, 'load_tests', None)  #然後判斷這個包裏面有沒有'load_tests'這個屬性---這裏我代碼一直看下來，我們是不知道這個lood_tests是什麼的，字面意思 加載測試集合
77             # Mark this package as being in load_tests (possibly ;))
78             self._loading_packages.add(name)  #然後把模塊名稱添加到set集合
79             try:
80                 tests = self.loadTestsFromModule(package, pattern=pattern)   
81                 #這裏傳了一個package模塊對象,和文件匹配規則合作或者文件。。--但是這裏導入一個包之後實際上是找不到testCase的-因為包下面的屬性肯定不是一個類-不會走loadTestsFromTestCase
82                 #所以這裏返回的tests是一個空列表
83                 if load_tests is not None: #貌似這個是棄用的，向後兼容-暫時沒看明白這個load_tests代表的意思
84                     # loadTestsFromModule(package) has loaded tests for us.
85                     return tests, False
86                 return tests, True  #  如果能走到這裏------就返回True_就是給_find_test判斷走遞歸的--_find_tests裏面就得到 should_recurse=True
87             finally:
88                 self._loading_packages.discard(name)  #然後這個刪掉set集合裏面之前導入的那個包
89         else:
90         return None, False

View Code

 1 def loadTestsFromModule(self, module, *args, pattern=None, **kws):
 2     """Return a suite of all test cases contained in the given module"""
 3     # This method used to take an undocumented and unofficial
 4     # use_load_tests argument.  For backward compatibility, we still
 5     # accept the argument (which can also be the first position) but we
 6     # ignore it and issue a deprecation warning if it's present.
 7     if len(args) > 0 or 'use_load_tests' in kws:    #args這個默認是一個空元組  長度默認為0  kws是一個空字典
 8         warnings.warn('use_load_tests is deprecated and ignored',
 9                       DeprecationWarning)
10         kws.pop('use_load_tests', None)
11     if len(args) > 1:
12         # Complain about the number of arguments, but don't forget the
13         # required `module` argument.
14         complaint = len(args) + 1
15         raise TypeError('loadTestsFromModule() takes 1 positional argument but {} were given'.format(complaint))
16     if len(kws) != 0:
17         # Since the keyword arguments are unsorted (see PEP 468), just
18         # pick the alphabetically sorted first argument to complain about,
19         # if multiple were given.  At least the error message will be
20         # predictable.
21         complaint = sorted(kws)[0]  #取出第一個Key-
22         raise TypeError("loadTestsFromModule() got an unexpected keyword argument '{}'".format(complaint))
23     tests = []
24     for name in dir(module):    #這裏得modul實際上使我們傳入的模塊對象---dir(object)  返回模塊下的所有屬性列表-
25         obj = getattr(module, name)   #然後反射返回name對象。。返回的是一個class對象
26         if isinstance(obj, type) and issubclass(obj, case.TestCase):    #這裏判斷obj是否是一個類--並且這個類是case.TestCase的子類，也就是說 是否寫在我們繼承unitest.testCase那個類的下面
27             tests.append(self.loadTestsFromTestCase(obj))  #可以看到最後走loadTestFromTestCase obj這裡是傳入的一個類名
28 
29     load_tests = getattr(module, 'load_tests', None)
30     tests = self.suiteClass(tests)
31     if load_tests is not None:
32         try:
33             return load_tests(self, tests, pattern)
34         except Exception as e:
35             error_case, error_message = _make_failed_load_tests(
36                 module.__name__, e, self.suiteClass)
37             self.errors.append(error_message)
38             return error_case
39     return tests  #返回集合

View Code loadTestsFromTestCase：這裏就是添加testcase到suit集合裏面的主要邏輯

 1 def loadTestsFromTestCase(self, testCaseClass):  #testCaseClass是我們傳的一個用例類
 2     """Return a suite of all test cases contained in testCaseClass"""
 3     if issubclass(testCaseClass, suite.TestSuite):  #這個類是不是suite.TestSuite的子類--如果是的就拋出異常==
 4         raise TypeError("Test cases should not be derived from "
 5                         "TestSuite. Maybe you meant to derive from "
 6                         "TestCase?")
 7     testCaseNames = self.getTestCaseNames(testCaseClass)  #getTestCaseNames  從類下面找到用例名稱--找到名稱返回的是一個列表
 8     if not testCaseNames and hasattr(testCaseClass, 'runTest'):  #這裏判斷testCaseNames是否為空-並且 是否存在"runTest"這個元素
 9         testCaseNames = ['runTest']
10     loaded_suite = self.suiteClass(map(testCaseClass, testCaseNames)) #是我的一個用例類--然後將testCaseNames類下面的測試方法--帶進去遍歷。。。高級用法---第一次見--這個方法很關鍵
11     return loaded_suite

View Code getTestCaseNames

 1 def getTestCaseNames(self, testCaseClass):
 2     """Return a sorted sequence of method names found within testCaseClass
 3     """
 4     def isTestMethod(attrname, testCaseClass=testCaseClass,   #定義一個內部方法
 5                      prefix=self.testMethodPrefix):     #self.testMethodPrefix="test"   這個在TestLoader下第一行就已經默認了，他是我們用例開頭的固定格式
 6         return attrname.startswith(prefix) and \  #這裏判斷了是否已test開頭以及 方法對象是否可用----getattr返回方法對象--callable()是檢測對象是否可用    返回一個布爾值
 7             callable(getattr(testCaseClass, attrname))
 8     testFnNames = list(filter(isTestMethod, dir(testCaseClass)))
 9      #dir(testCaseClass)返回該對象下面所有的屬性--包括變量test_1--所以上面需要檢測屬性時test開頭且是一個可以調用的對象--
10      #filter函數---前面是一個function -後面是一個可迭代對象-會遍歷可迭代對象-並傳入function-functions返回true則添加到列表--這樣就找到了所有的
11     if self.sortTestMethodsUsing:
12         testFnNames.sort(key=functools.cmp_to_key(self.sortTestMethodsUsing))     
13         #sortTestMethodsUsing = staticmethod(util.three_way_cmp) 轉為為靜態方法-內存地址指向self.sortTestMethodsUsing
14         #然後通過functools這個模塊排序==
15     return testFnNames  #然後返回用例方法名稱列表

View Code 所有的邏輯 就是在TestLoader找測試用例的時候–通過_find_tests這個方法從目錄開始找文件(子目錄)-模塊-類-方法名 然後將某個模塊下的類通過他下面的方法map返回多個對象，也就是說一個testClass下面存在五個test_method，他就會返回五個實例對象-並生成一個suite集合–然後加入到一個列表 如果一個模塊下有多個testClasee 同樣-實際上是一樣的–實際上他是先通過loadTestsFromModule這個方法找到所有的類對象之後在遍歷–然後才走上面那一步的，，，多個testClasss就存在多個suite集合– 也就是說 一個modul下面的 suite集合會添加到一個列表–[suite=[A-TestCase實例化對象1,A-TestCase實例化對象2]，suite=[B-TestCase實例化對象1，B-TestCase實例化對象2]]—然後在將這個列表當做參數傳入TestSuite實例化一個新對象[suite=-[suite=[A-TestCase實例化對象1,A-TestCase實例化對象2]，suite=[B-TestCase實例化對象1，B-TestCase實例化對象2]]]—-這樣就是一個模塊下用的結構 但是還沒有完–這裏只是一個modul下的—還有多個modul–到了大家估計也知道剩下的會幹什麼了— 沒錯–當我得到modul的全部suite集合之後—這個集合最終會返回給_find_tests方法–通過生成器返回給discover–也就是將這個suite集合又加入到了一個新的列表–然後discover又將這個list 帶入形成了一個—–最終的實例對象，最終返回的格式如下——- [suite= [suite1=-[suite=[A-TestCase實例化對象1,A-TestCase實例化對象2]，suite=[B-TestCase實例化對象1，B-TestCase實例化對象2]]], [suite2=-[suite=[A-TestCase實例化對象1,A-TestCase實例化對象2]，suite=[B-TestCase實例化對象1，B-TestCase實例化對象2]]] ]   –看過源碼的都知道—我們run的時候—就這個實例對象是可以接受參數的–而這個參數就是result—因為TestSuite繼承的BaseTestsSuite 有一個__call__這個
魔術方法：如果在類中實現了 __call__ 方法，那麼實例對象也將成為一個可調用對象，具體百度。這裏不做過多解釋—–所以最終的suite是可以接受參數的test(result)–接受參數之後直接走——call下面的邏輯了 本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

萬級TPS億級流水-中台賬戶系統架構設計

標籤：高併發 萬級TPS 億級流水 賬戶系統

• 背景
• 業務模型
• 應用層設計
• 數據層設計
• 日切對賬

背景

我們需要給所有前台業務提供統一的賬戶系統，用來支撐所有前台產品線的用戶資產管理，統一提供支持大併發萬級TPS、億級流水、數據強一致、風控安全、日切對賬、財務核算、審計等能力，在萬級TPS下保證絕對的數據準確性和數據溯源能力。

注：資金類系統只有合格和不合格，哪怕數據出現只有0.01分的差錯也是不合格的，局部數據不準也就意味着全局數據都不可信。

本文只分享系統的核心模型部分的設計，其他常規類的（如壓測驗收、系統保護策略-限流、降級、熔斷等）設計就不做多介紹，如果對其他方面有興趣歡迎進一步交流。

業務模型

基本賬戶管理： 根據交易的不同主體，可以分為個人賬戶、機構賬戶。
賬戶餘額在使用上沒有任何限制，很純粹的賬戶存儲、轉賬管理，可以滿足90%業務場景。

子賬戶功能： 一個用戶可以開通多個子賬戶，根據餘額屬性不同可以分為基本賬戶、過期賬戶，根據幣種不同可以分為人民幣賬戶、虛擬幣賬戶，根據業務形態不同可以自定義。
（不同賬戶的特定功能是通過賬戶上的賬戶屬性來區分實現。）

過期賬戶管理： 該賬戶中的餘額是會隨着進賬流水到期自動過期。
如：在某平台充值1000元送300元，其中300元是有過期時間的，但是1000元是沒有時間限制的。這裏的1000元存在你的基本賬戶中，300元存在你的過期賬戶中。

注：過期賬戶的每一筆入賬流水都會有一個到期時間。系統根據交易流水的到期時間，自動核銷用戶過期賬戶中的餘額，記為平台的確認收入。

賬戶組合使用：支持多賬戶組合使用，根據配置的優先扣減順序進行扣減餘額。比如：在 基本賬戶 和 過期賬戶 （充值賬戶）中扣錢一般的順序是優先扣減過期賬戶的餘額。

應用層設計

根據上述業務模型，賬戶系統是一個典型的 數據密集型系統 ，業務層的邏輯不複雜。整個系統的設計關鍵點在於如何平衡大併發TPS和數據一致性。

熱點賬戶：前台直播類業務存在熱點賬戶問題，每到各種活動賽事的時候會存在 90%DAU 給少數幾個頭部主播打賞的場景。
DB就會有熱點行問題，由於 行鎖 關係併發一大肯定大量超時、RT突增 、 DB活躍線程 增加等一系列問題，最終DB會被拖掛。

賬戶類系統有一個特點，原賬戶的扣減可以實時處理，目標賬戶可以異步處理，我們可以將轉賬動作拆解為兩個階段進行異步化。（可以參考銀行轉賬業務。）

比如：A給B轉賬100元，原賬戶A的100元餘額扣減可以同步處理，B賬戶的100增加可以異步處理。這樣哪怕10w人給主播打賞，這10w人的賬戶都是分散的，而主播的餘額增加則是異步處理的。

賬戶轉賬扣減A賬戶餘額，記錄A賬戶出賬流水，記錄B賬戶入賬流水，這三個動作可以在一個DBTransaction中處理，可以保證源賬戶進出帳一致性。目標賬戶B的入賬可以異步處理，為了保證萬無一失且滿足一定的實時性，需要兩步結合，程序里通過MQ走異步入賬，同時增加DB的兜底JOB定時掃描 入賬流水記錄 為未到賬的流水進行入賬。

我們通過異步化緩解熱點行處理，但是如果 收款方 強烈要求收款必須在一定的時間內完成，我們還是需要進一步處理，後面會講到。

過期賬戶： 通常過期賬戶用來管理贈送類賬戶，這類賬戶有一定的時效性，用戶在使用上也是優先扣減此類賬戶餘額。
這類使用需求其實覆蓋面不大，真正用戶賬戶餘額不使用等着被系統過期的很少，畢竟這是一個很傻的行為。

過期賬戶的兩種核銷情況：第一種是用戶使用過期賬戶時的核銷。第二種是某個過期流水到了過期時間，系統自動核銷記為平台的確認收入。

過期賬戶核銷邏輯：用戶充值1000元到基本賬戶，平台贈送300元到贈送賬戶。此時，基本賬戶記錄進賬流水+1000元，贈送賬戶記錄進賬流水+300元並且該筆流水的過期時間為 2020-12-29 23:59:59 （過期時間由前台業務方設置） 。

系統自動核銷：如果用戶不在此時間之前用完就會被系統自動划進平台的收入，贈送賬戶餘額扣減-300元。

用戶使用核銷：如果用戶在過期時間前陸續在使用贈送賬戶，比如使用100元，那麼我們需要核銷原本進賬的300元的那筆流水，減少-150元。
也就是說，該筆過期流水已經核銷掉150元，帶過期核銷150元，到期后只要核銷150元即可，而不是300元。

過期賬戶每次使用均產生待核銷負向流水，系統自動核銷前必須保證沒有任何負向流水記錄才可以去扣減贈送賬戶餘額。

考慮到極端情況下，剛好過期JOB在進行自動過期核銷，用戶又在此時使用過期賬戶，這點需要注意下。可以簡單通過加DB-X鎖解決，這個場景其實非常稀少。

數據層設計

在應用層設計的時候，我們通過異步化方式來繞開熱點問題。
同樣我們在設計數據層的時候也要考慮單次操作DB的性能，比如控制事務的大小，事務跨網絡的次數等問題。當然還包括金額存儲的精度問題，精度問題處理不好也會影響性能。

浮點數問題： 如果我們用浮點數近似值來存儲金額，那麼就一定會有偏差，隨着金額越大時間越長偏差就會越大。比較好的方式是通過整型來存儲，通過放大金額比例來達到不同的業務場景下對金額比率的要求。

正常的1.12元，存儲比率是1=100元，那麼表裡的存儲值就是112，不同的貨幣比例都可以自由縮放，永遠都可以保持最準確的精度。

分庫分表+讀寫分離： 根據業務特點和未來增量規劃，將DB分為16個邏輯庫，前期使用2個物理庫承載。16個邏輯庫，按照每次2倍擴容，最大擴容上限是16個物理庫。單實例的配置 8c 32g 2t 8000conn 9000iops 。

按照單次TPS-rt 1ms計算，TPS 1w 需求，每台承載5k TPS，單庫的活躍線程大概在8-10個（考慮網絡延遲）。
最後到達瓶頸的都是iops，因為只要rt足夠短，最終壓力都會在IO上。

分庫按照uid分為16個庫，賬戶表不分表默認16張。每張表按照 1kw*16=1.6 億個賬戶。

單表能存儲多少要綜合考慮，比如查詢類型，單次查詢的RT，冷熱數據佔比（ innodb_buffer_pool 利用率）、是否充分發揮了索引，索引是否達到3星級別，索引片中沒有經常變更的字段等。

賬戶流水表按照日期分表365張，流水數據會隨着時間推移逐漸變成冷數據，定期歸檔冷數據。（這裏約定了，流水查詢只能按照uid+日期查詢。如果運營類的需求，要橫跨分片key獲取，走OLAP方案 clickhouse、hive等）

分庫分表採用阿里雲分佈式數據庫產品DRDS，1個主庫集群+2個讀庫集群（讀庫做了讀負載均衡，可以按需擴容）。

讀負載均衡器：https://github.com/Plen-wang/read-loadbalance

既然用了DRDS分佈式數據庫產品，那麼在查詢上需要充分考慮分片鍵的限制，如果存儲和查詢出現分片鍵衝突問題就需要我們手動計算分片路由，直接訪問物理節點。

訪問物理節點需要藉助DRDS專用SQL註釋子句來完成。

先通過 show node 查看物理DB ID、show topology from logic_table_name 查看物理表ID，然後在SQL帶上特定的註釋子句。

SELECT /*+TDDL:scan('logic_table_name', real_table=("real_table_name"),node='real_db_node_id')*/ 
count(1) FROM logic_table_name ;

賬戶更新： 對賬戶更新都有一個前提就是賬戶已經開通，但是我們為了最大化賬戶系統在使用上的便利性，讓前台業務方不需要做初始化動作，由賬戶系統惰性初始化，比如發現賬戶不存在就自動初始化賬戶數據。

但是我們怎麼知道賬戶不存在，不可能每次都去查詢一次或者根據執行返回錯誤判斷。而且 update 語句是區分不了錯誤的 賬戶不存在 還是 餘額不足 或者其他原因。

那麼如何巧妙的解決這個問題，只要一次DB往返。

我們可以使用 Mysql INSERT INTO ... ON DUPLICATE KEY UPDATE ... 子句，但是該子句有一個限制就是不支持 where 子句。

-- cut_version 樂觀鎖、account_property 賬戶屬性
insert into tb_account(uid,balance,cut_version,account_property) values("%s",%d,%d,%d) ON DUPLICATE KEY UPDATE balance = balance + %d,cut_version = cut_version+1

其實不完全推薦使用這個方法，因為這個方法也有弊端就是將來 where 子句無法使用，還有一個辦法就是合併 賬戶查詢 和 插入 為一條 sql 提交。

DB操作本身rt可能很短，但是如果跨網絡那麼事務的延遲會帶來DB的串行化增加，降低併發度，整體應用 rt就會增加。所以一個原則就是盡量不要跨網絡開事務，合併sql做一次事務提交，最短的事務周期，減少跨網絡的事務操作，如果我們將單次事務網絡交互減少2-3次，性能的提高可能會增加2-3倍，同樣由於網絡的不穩定抖動丟包對 999rt 線的影響也會減少2-3倍。

平衡好當前系統是業務密集型還是數據密集型。
判斷當前系統是否有很強的業務層邏輯，是否要運用DDD、RUP等強模型的工程方法。畢竟強模型和高性能在落地的時候有些方面是衝突的，需要進一步藉助 CRQS、GRASP等工程方法來解決。

單行熱點問題： 單行的TPS都是串行的，事務rt越短TPS就越高，按照1ms計算，差不多TPS就是1000。一般只有機構賬戶類型才會有這個需求。

我們可以將單行變成多行，增加行的并行度，加大賬戶操作的併發度。（這個方案要評估好寫入和查詢兩端需求）

id	uid	balance	slot
1	10101010	1000	1
2	10101010	2000	2
3	10101010	3000	3
4	10101010	400	4
5	10101010	300	5
6	10101010	200	6
7	10101010	200	7
8	10101010	200	8
9	10101010	200	9
10	10101010	200	10

insert into tb_account (uid,balance,slot)
values(10101010, 1000, round(rand()*9)+1) 
on  duplicate key update balance=balance+values(balance)

這裏的 10slot*單個slot 1000TPS，理論上可以跑到1w，如果機構賬戶數據量很大，可以擴展slot個數。

賬戶的總餘額通過sum()匯總，如果業務場景中有餘額的頻繁sum()操作，可以通過增加餘額中間表，定期 insert into tb_account_total select sum(balance) total_balance from tb_account group by uid 。

通常機構賬戶的結算是有周期的（T+7、T+30等），而且基本是沒有併發，所以在賬戶餘額扣減方面就可以輕鬆處理。
有兩種實現方案：

第一種，賬戶餘額允許單個slot為負數，但是總的sum()是正數。通過子查詢來對餘額進行檢查。

insert into tb_account (uid, balance, slot)
select uid,-1000 as balance,round(rand() *9+ 1)
from(
    select uid, sum(balance) as ss
    from tb_account
    where uid= 10101010
    group by uid having ss>= 1000 for update) as tmp
on duplicate key update balance= balance+ values(balance)

第二種，如果條件允許可以藉助用戶自定義變量來在DB上完成餘額累計掃描，將可以扣減的slot的主鍵id返回給程序，但是只需要一次DB交互就可以獲取出可以扣減的賬戶solt，然後分別開始對slot賬戶進行扣減。

set @f:=0;
select * from tb_account where id in(select id from (select id, @f:=@f+balance from tb_account where @f<1000 order by id) as t);

第二種方案在默認的mysql數據庫上都是支持的，但是有些數據庫雲產品不支持，阿里雲rds是不支持的。

日切對賬

賬戶系統有一個基本的需求，就是每天餘額鏡像，簡單講就是餘額在每天的快照，用來做T+1對賬。
不管財務還是每季度的審計都會需要，最重要的是我們自己也需要對賬戶數據做摸底對賬。

由於每天產生上億的流水，這需要在大數據平台中完成。

日切對賬：昨天賬戶餘額 – 前天賬戶餘額 = 昨天的流水 – 前天的流水。

比如，昨天的賬戶餘額是5000w，前台的賬戶餘額是4500w，差值就是500w。同樣道理，昨天的賬戶流水是5000w，前天的賬戶流水是4500w，那麼差值是500w，這就是沒問題的。

賬戶不僅有增加也有減少，可能昨天賬戶餘額比前天賬戶餘額差值是-500w，但是流水也要是-500w才行。

由於每天會產生億級的流水，用傳統的全量抽取不現實，這類數據抽取的速度都會有延遲，而且對賬最重要的是時間點必須非常精準，才能保證餘額和流水是對得上的。

要不然會出現HDFS的分區是2020-06-10號，但是該分區里有2020-06-11的數據，就是因為拉取的時候會延遲到第二天。這個問題也可以通過增加拉取sql的條件限制來解決這個問題，但是無法做到0點瞬間鏡像全部賬戶。

解決方案： 全量餘額+binlog增量更新
1.賬戶表，先做一次全量同步。
2.DB的所有變更通過binlog（默認row複製）進到數倉。（因為 binlog 是基於發生時間的，所以無所謂我們是不是在0點去計算鏡像）
3.T+1跑JOB的時候，獲取前一天的賬戶餘額，然後通過 binlog 來覆蓋前天與昨天的交集部分。

由於數倉的 binlog 數據都是增量的，所以要想取到正確的全量數據需要用到一定的技巧。

select app_id,sub_type,sum(amount) records_amount from (
      select *,row_number()over(partition by id order by updated_at) as rn
      from hive_db_table
      where dt='${YESTERDAY}'
  ) t where t.rn=1
       group by t.sub_type,t.app_id

使用 hive 開窗函數 row_number()over() 對同樣的id進行分組，然後獲取最新的一條數據就是賬戶在T的最後的值。

作者：王清培（趣頭條 Tech Leader）

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

亞洲巴士車身製造商及裝配商彭順國際有限公司宣佈，集團間接全資附屬公司Gemilang Coachwork Sdn. Bhd.與加拿大電動車開發商GreenPower Motor Company Inc.今天於集團馬來西亞總部舉行了交付及簽署儀式。

儀式上，Gemilang Coachwork向GreenPower交付了首部以美國規格製造的電動校巴樣車；同時，雙方訂立合作協議，以發掘美國及加拿大市場未來潛在訂單及共享專有技術的業務機遇。 彭順國際有限公司行政總裁彭中庸表示︰「電動車是全球發展的大方向，發展潛力十分龐大，配合集團與GreenPower雙方的技術與資源，相信是次合作會達到正面的結果。而更重要的是，與GreenPower的合作除了證明集團的市場地位得到高度認可，亦有利集團借助對方的網絡，把業務進一步擴展至等美國及加拿大等國際市場。」

（本文內容由授權使用。圖片出處：GreenPower）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

根據櫃買中心重大訊息公告，電動車及輔具廠商必翔實業，因子公司仍有許多待釐清事項，財報無法如期交出，因此18 日起將暫停交易。而且檢調也對必翔實業進行搜索，並且約談董事長蔣伍清明。在無法如期交出財報的消息傳出後，必翔16 日股價再度跌停板，已經連續10 個交易日跌停，股價由54.6 元下跌至每股19.2 元，跌幅超過64%。

據了解，必翔旗下子公司必翔電，近年在中國積極發展磷酸鋰鐵電池，而且在2014 年底獲得寧波雙鹿集團簽署新能源項目合作暨商務採購協議，當時成為能源類股當紅炸子雞。但是，由於中國官方的電動車補助政策改變，使得必翔電出貨受阻之外，還面臨收款不順的困境。

近期必翔電的輔導券商元大證，以及協辦券商德信證雙雙辭任雙雙辭任，還出現董事解職潮。未來，若無法順利找到輔導的券商，必翔電恐將面臨自興櫃下市的處境。

而根據必翔的公告指出，必翔之所以未能如期提交首季財報，主要因子公司揚明實業 （浙江） 在寧波所開立的二家銀行帳戶現金及相關投資理財商品合計人民幣1.7 億元，其管理及控制的合理性有待釐清。另外，另一子公司必翔電能方面共有包括營收、應收帳款、備抵呆帳以及存貨等合理性，也有進一步釐清的必要。該公司公告表示，已啟動跨境查核專案，委請專業人員組成查核小組跨境查核，將會盡速釐清問題，再補行公告。

而對於必翔無法如期交出財報，證交所表示將依證交所營業細則第50 條第1 項第1 款規定情事，公告自5 月18 日起，將停止有價證券之買賣。另外，檢調單位也於16 日至必翔公司進行搜索，並約談董事長蔣伍清明。

（合作媒體：。圖片出處：必翔）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

Dragonfly 是一款基於 P2P 的智能鏡像和文件分發工具。它旨在提高文件傳輸的效率和速率，最大限度地利用網絡帶寬，尤其是在分發大量數據時，例如應用分發、緩存分發、日誌分發和鏡像分發。

在阿里巴巴，Dragonfly 每個月會被調用 20 億次，分發的數據量高達 3.4PB。Dragonfly 已成為阿里巴巴基礎設施中的重要一環。

儘管容器技術大部分時候簡化了運維工作，但是它也帶來了一些挑戰：例如鏡像分發的效率問題，尤其是必須在多個主機上複製鏡像分發時。

Dragonfly 在這種場景下能夠完美支持 Docker 和 PouchContainer。它也兼容其他格式的容器。相比原生方式，它能將容器分發速度提高 57 倍，並讓 Registry 網絡出口流量降低 99.5%。
Dragonfly 能讓所有類型的文件、鏡像或數據分發變得簡單而經濟。

更多請通過官方文檔了解。

純Docker部署

這裏採用多機部署，方案如下：

應用	IP
服務端	172.17.100.120
客戶端	172.17.100.121
客戶端	172.17.100.122

部署服務端

以docker方式部署，命令如下：

docker run -d --name supernode --restart=always -p 8001:8001 -p 8002:8002 \
    dragonflyoss/supernode:0.3.0 -Dsupernode.advertiseIp=172.17.100.120

部署客戶端

準備配置文件
Dragonfly 的配置文件默認位於 /etc/dragonfly 目錄下，使用容器部署客戶端時，需要將配置文件掛載到容器內。
為客戶端配置 Dragonfly Supernode 地址：

cat <<EOD > /etc/dragonfly/dfget.yml
nodes:
    - 172.17.100.120
EOD

啟動客戶端

docker run -d --name dfclient --restart=always -p 65001:65001 \
    -v /etc/dragonfly:/etc/dragonfly \
    dragonflyoss/dfclient:v0.3.0 --registry https://index.docker.io

registry是倉庫地址，這裏使用的官方倉庫

修改Docker Daemon配置

我們需要修改 Dragonfly 客戶端機器（dfclient0, dfclient1）上 Docker Daemon 配置，通過 mirror 方式來使用 Dragonfly 進行鏡像的拉取。
在配置文件 /etc/docker/daemon.json 中添加或更新如下配置項：

{
  "registry-mirrors": ["http://127.0.0.1:65001"]
}

然後重啟Docker

systemctl restart docker

拉取鏡像測試

在任意一台客戶端上進行測試，比如：

docker pull tomcat

驗證

查看client端的日誌，如果輸出如下，則表示是通過DragonFly來傳輸的。

docker exec dfclient grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log

2020-06-20 15:56:49.813 INFO sign:146-1592668602.159 : downloading piece:{"taskID":"4d977359836129ce2eec4b8418a7042c47db547a239e2a577ddc787ee177289c","superNode":"172.17.100.120","dstCid":"cdnnode:172.17.100.120~4d977359836129ce2eec4b8418a7042c47db547a239e2a577ddc787ee177289c","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}

如果需要查看鏡像是否通過其他 peer 節點來完成傳輸，可以執行以下命令：

docker exec dfclient grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log | grep -v cdnnode

如果以上命令沒有輸出結果，則說明鏡像沒有通過其他peer節點完成傳輸，否則說明通過其他peer節點完成傳輸。

在Kubernetes中部署

服務端以Deployment的形式部署

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: supernode
  name: supernode
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: supernode
  template:
    metadata:
      labels:
        app: supernode
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ""
    spec:
      containers:
      - image: dragonflyoss/supernode:0.3.0
        name: supernode
        ports:
        - containerPort: 8080
          hostPort: 8080
          name: tomcat
          protocol: TCP
        - containerPort: 8001
          hostPort: 8001
          name: register
          protocol: TCP
        - containerPort: 8002
          hostPort: 8002
          name: download
          protocol: TCP
        volumeMounts:
        - mountPath: /etc/localtime
          name: ltime
        - mountPath: /home/admin/supernode/logs/
          name: log
        - mountPath: /home/admin/supernode/repo/
          name: data
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      restartPolicy: Always
      tolerations:
      - effect: NoExecute
        operator: Exists
      - effect: NoSchedule
        operator: Exists
      nodeSelector:
        node-role.kubernetes.io/master: ""
      volumes:
      - hostPath:
          path: /etc/localtime
          type: ""
        name: ltime
      - hostPath:
          path: /data/log/supernode
          type: DirectoryOrCreate
        name: log
      - hostPath:
          path: /data/supernode/repo/
          type: DirectoryOrCreate
        name: data

---
kind: Service
apiVersion: v1
metadata:
  name: supernode
  namespace: kube-system
spec:
  selector:
    app: supernode
  ports:
  - name: register
    protocol: TCP
    port: 8001
    targetPort: 8001
  - name: download
    protocol: TCP
    port: 8002
    targetPort: 8002

以hostNetwork的形式部署在master上。

部署過後可以看到supernode已經正常啟動了。

# kubectl get pod -n kube-system | grep supernode
supernode-86dc99f6d5-mblck                 1/1     Running   0          4m1s

客戶端以daemonSet的形式部署，yaml文件如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dfdaemon
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: dfdaemon
  template:
    metadata:
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        app: dfdaemon
    spec:
      containers:
      - image: dragonflyoss/dfclient:v0.3.0
        name: dfdaemon
        imagePullPolicy: IfNotPresent
        args:
        - --registry https://index.docker.io
        resources:
          requests:
            cpu: 250m
        volumeMounts:
        - mountPath: /etc/dragonfly/dfget.yml
          subPath: dfget.yml
          name: dragonconf
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      restartPolicy: Always
      tolerations:
      - effect: NoExecute
        operator: Exists
      - effect: NoSchedule
        operator: Exists
      volumes:
      - name: dragonconf
        configMap:
          name: dragonfly-conf

配置文件我們以configMap的形式掛載，所以我們還需要編寫一個configMap的yaml文件，如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: dragonfly-conf
  namespace: kube-system
data:
  dfget.yml: |
    nodes:
    - 172.17.100.120

部署過後觀察結果

# kubectl get pod -n kube-system | grep dfdaemon
dfdaemon-mj4p6                             1/1     Running   0          3m51s
dfdaemon-wgq5d                             1/1     Running   0          3m51s
dfdaemon-wljt6                             1/1     Running   0          3m51s

然後修改docker daemon的配置，如下：

{
  "registry-mirrors": ["http://127.0.0.1:65001"]
}

重啟docker

systemctl restart docker

現在我們來拉取鏡像測試，並觀察日誌輸出。
下載鏡像（在master上測試的）：

docker pull nginx

然後觀察日誌

kubectl exec  -n kube-system dfdaemon-wgq5d  grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log

看到日誌輸出如下，表示成功

2020-06-20 17:14:54.578 INFO sign:128-1592673287.190 : downloading piece:{"taskID":"089dc52627a346df2a2ff67f6c07497167b35c4bad2bca1e9aad087441116982","superNode":"172.17.100.120","dstCid":"cdnnode:192.168.235.192~089dc52627a346df2a2ff67f6c07497167b35c4bad2bca1e9aad087441116982","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}

今天的測試就到這裏，我這是自己的小集群實驗室，效果其實並不明顯，在大集群效果可能更好。

• 參考
  • https://d7y.io/zh-cn/docs/userguide/multi_machines_deployment.html

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

原來你是這樣的BERT，i了i了！ —— 超詳細BERT介紹（一）BERT主模型的結構及其組件

BERT（Bidirectional Encoder Representations from Transformers）是谷歌在2018年10月推出的深度語言表示模型。

一經推出便席捲整個NLP領域，帶來了革命性的進步。
從此，無數英雄好漢競相投身於這場追劇（芝麻街）運動。
只聽得這邊G家110億，那邊M家又1750億，真是好不熱鬧！

然而大家真的了解BERT的具體構造，以及使用細節嗎？
本文就帶大家來細品一下。

前言

本系列文章分成三篇介紹BERT，本文主要介紹BERT主模型（BertModel）的結構及其組件相關知識，另有兩篇分別介紹BERT預訓練相關和如何將BERT應用到不同的下游任務。

文章中的一些縮寫：NLP（natural language processing）自然語言處理；CV（computer vision）計算機視覺；DL（deep learning）深度學習；NLP&DL 自然語言處理和深度學習的交叉領域；CV&DL 計算機視覺和深度學習的交叉領域。

文章公式中的向量均為行向量，矩陣或張量的形狀均按照PyTorch的方式描述。
向量、矩陣或張量后的括號表示其形狀。

本系列文章的代碼均是基於transformers庫（v2.11.0）的代碼（基於Python語言、PyTorch框架）。
為便於理解，簡化了原代碼中不必要的部分，並保持主要功能等價。
在代碼最開始的地方，需要導入以下包：

代碼

from math import inf, sqrt
import torch as tc
from torch import nn
from torch.nn import functional as F
from transformers import PreTrainedModel

閱讀本系列文章需要一些背景知識，包括Word2Vec、LSTM、Transformer-Base、ELMo、GPT等，由於本文不想過於冗長（其實是懶），以及相信來看本文的讀者們也都是衝著BERT來的，所以這部分內容還請讀者們自行學習。
本文假設讀者們均已有相關背景知識。

目錄

• 1、主模型
  • 1.1、輸入
  • 1.2、嵌入層
    • 1.2.1、嵌入變換
    • 1.2.2、層標準化
    • 1.2.3、隨機失活
  • 1.3、編碼器
    • 1.3.1、隱藏層
      • 1.3.1.1、線性變換
      • 1.3.1.2、激活函數
        • 1.3.1.2.1、tanh
        • 1.3.1.2.2、softmax
        • 1.3.1.2.3、GELU
      • 1.3.1.3、多頭自注意力
      • 1.3.1.4、跳躍連接
  • 1.4、池化層
  • 1.5、輸出

1、主模型

BERT的主模型是BERT中最重要組件，BERT通過預訓練（pre-training），具體來說，就是在主模型后再接個專門的模塊計算預訓練的損失（loss），預訓練后就得到了主模型的參數（parameter），當應用到下游任務時，就在主模型後接個跟下游任務配套的模塊，然後主模型賦上預訓練的參數，下游任務模塊隨機初始化，然後微調（fine-tuning）就可以了（注意：微調的時候，主模型和下游任務模塊兩部分的參數一般都要調整，也可以凍結一部分，調整另一部分）。

主模型由三部分構成：嵌入層、編碼器、池化層。
如圖：

其中

• 輸入：一個個小批（mini-batch），小批里是batch_size個序列（句子或句子對），每個序列由若干個離散編碼向量組成。
• 嵌入層：將輸入的序列轉換成連續分佈式表示（distributed representation），即詞嵌入（word embedding）或詞向量（word vector）。
• 編碼器：對每個序列進行非線性表示。
• 池化層：取出[CLS]標記（token）的表示（representation）作為整個序列的表示。
• 輸出：編碼器最後一層輸出的表示（序列中每個標記的表示）和池化層輸出的表示（序列整體的表示）。

下面具體介紹這些部分。

1.1、輸入

一般來說，輸入BERT的可以是一句話：

I'm repairing immortals.

也可以是兩句話：

I'm repairing immortals. ||| Me too.

其中|||是分隔兩個句子的分隔符。

BERT先用專門的標記器（tokenizer）來標記（tokenize）序列，雙句標記后如下（單句類似）：

I ' m repair ##ing immortal ##s . ||| Me too .

標記器其實就是先對句子進行基於規則的標記化（tokenization），這一步可以把'm以及句號.等分割開，再進行子詞分割（subword segmentation），示例中帶##的就是被子詞分割開的部分。
子詞分割有很多好處，比如壓縮詞彙表、表示未登錄詞（out of vocabulary words, OOV words）、表示單詞內部結構信息等，以後有時間專門寫一篇介紹這個。

數據集中的句子長度不一定相等，BERT採用固定輸入序列（長則截斷，短則填充）的方式來解決這個問題。
首先需要設定一個seq_length超參數（hyperparameter），然後判斷整個序列長度是否超出，如果超出：單句截掉最後超出的部分，雙句則先刪掉較長的那句話的末尾標記，如果兩句話長度相等，則輪流刪掉兩句話末尾的標記，直到總長度達到要求（即等長的兩句話刪掉的標記數量盡量相等）；如果序列長度過小，則在句子最後添加[PAD]標記，使長度達到要求。

然後在序列最開始添加[CLS]標記，以及在每句話末尾添加[SEP]標記。
單句話添加一個[CLS]和一個[SEP]，雙句話添加一個[CLS]和兩個[SEP]。
[CLS]標記對應的表示作為整個序列的表示，[SEP]標記是專門用來分隔句子的。
注意：處理長度時需要考慮添加的[CLS]和[SEP]標記，使得最終總的長度=seq_length；[PAD]標記在整個序列的最末尾。

例如seq_length=12，則單句變為：

[CLS] I ' m repair ##ing immortal ##s . [SEP] [PAD] [PAD]

如果seq_length=10，則雙句變為：

[CLS] I ' m repair [SEP] Me too . [SEP]

分割完后，每一個空格分割的子字符串（substring）都看成一個標記（token），標記器通過查表將這些標記映射成整數編碼。
單句如下：

[101, 146, 112, 182, 6949, 1158, 15642, 1116, 119, 102, 0, 0]

最後整個序列由四種類型的編碼向量表示，單句如下：

標記編碼：[101, 146, 112, 182, 6949, 1158, 15642, 1116, 119, 102, 0, 0]
位置編碼：[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
句子位置編碼：[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
注意力掩碼：[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0]

其中，標記編碼就是上面的序列中每個標記轉成編碼后得到的向量；位置編碼記錄每個標記的位置；句子位置編碼記錄每個標記屬於哪句話，0是第一句話，1是第二句話（注意：[CLS]標記對應的是0）；注意力掩碼記錄某個標記是否是填充的，1表示非填充，0表示填充。

雙句如下：

標記編碼：[101, 146, 112, 182, 6949, 102, 2508, 1315, 119, 102]
位置編碼：[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
句子位置編碼：[0, 0, 0, 0, 0, 0, 1, 1, 1, 1]
注意力掩碼：[1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

上面的是英文的情況，中文的話BERT直接用漢字級別表示，即

我在修仙（￣︶￣）↗

這樣的句子分割成

我 在 修 仙 （ ￣ ︶ ￣ ） ↗

然後每個漢字（包括中文標點）看成一個標記，應用上述操作即可。

1.2、嵌入層

嵌入層的作用是將序列的離散編碼錶示轉換成連續分佈式表示。
離散編碼只能表示A和B相等或不等，但是如果將其表示成連續分佈式表示（即連續的N維空間向量），就可以計算\(A\)與\(B\)之間的相似度或距離了，從而表達更多信息。
這個是詞嵌入或詞向量的知識，可以參考Word2Vec相關內容，本文不再贅述了。

嵌入層包含三種組件：嵌入變換（embedding）、層標準化（layer normalization）、隨機失活（dropout）。
如圖：

1.2.1、嵌入變換

嵌入變換實際上就是一個線性變換（linear transformation）。
傳統上，離散標記往往表示成一個獨熱碼（one-hot）向量，也叫標準基向量，即一個長度為\(V\)的向量，其中只有一位為\(1\)，其他都為\(0\)。
在NLP&DL領域，\(V\)一般是詞彙表的大小。
但是這種向量往往維數很高（詞彙表往往比較大）而且很稀疏（每個向量只有一位不為\(0\)），不好處理。
所以可以通過一個線性變換將這個向量轉換成低維稠密的向量。

假設\(v\)（\(V\)）是標記\(t\)的獨熱碼向量，\(W\)（\(V \times H\)）是一個\(V\)行\(H\)列的矩陣，則\(t\)的嵌入\(e\)為：

\[e = v W \]

實際上\(W\)中每一行都可以看成一個詞嵌入，而這個矩陣乘就是把\(v\)中等於\(1\)的那個位置對應的\(W\)中的詞嵌入取出來。
在工程實踐中，由於獨熱碼向量比較占內存，而且矩陣乘效率也不高，所以往往用一個整數編碼來代替獨熱碼向量，然後直接用查表的方式取出對應的詞嵌入。

所以假設\(n\)是\(t\)的編碼，一般是在詞彙表中的編號，那麼上面的公式就可以改成：

\[e = W_{n} \]

其中下標表示取出對應的行。

那麼一個標記化后的序列就可以表示成一個編碼向量。
假設序列\(T\)的編碼向量為\(s\)（\(L\)），\(L\)為序列的長度，即\(T\)中有\(L\)個標記。
如果詞嵌入長度為\(H\)，那麼經過嵌入變換，得到\(T\)的隱狀態（hidden state）\(h\)（\(L \times H\)）。

1.2.2、層標準化

層標準化類似於批標準化（batch normalization），可以加速模型訓練，但其實現方式和批標準化不一樣，層標準化是沿着詞嵌入（通道）維進行標準化的，不需要在訓練時存儲統計量來估計整體數據集的均值和方差，訓練（training）和評估（evaluation）或推理（inference）階段的操作是相同的。
另外批標準化對小批大小有限制，而層標準化則沒有限制。

假設輸入的一個詞嵌入為\(e = [x_0, x_1, …, x_{H-1}]\)，\(x_k\)是\(e\)第\(k = 0, 1, …, (H-1)\) 維的分量，\(H\)是詞嵌入長度。
那麼層標準化就是

\[y_{k} = \frac{x_{k}-\mu}{\sigma} * \alpha_k + \beta_k \]

其中，\(y_{k}\)是輸出，\(\mu\)和\(\sigma^2\)分別是均值和方差：

\[ \mu = \frac{1}{H} \sum_{k=0}^{H-1} x_{k} \\ \sigma^2 = \frac{1}{H} \sum_{k=0}^{H-1} (x_{k}-\mu)^2 \\ \]

\(\alpha_k\)和\(\beta_k\)是學習得到的參數，用於防止模型表示能力退化。

注意：\(\mu\)和\(\sigma^2\)是針對每個樣本每個位置的詞嵌入分別計算的，而\(\alpha_k\)和\(\beta_k\)對所有的詞嵌入都是共用的；\(\sigma^2\)的計算沒有使用貝塞爾校正（Bessel’s correction）。

1.2.3、隨機失活

隨機失活是DL領域非常著名且常用的正則化（regularization）方法（然而被谷歌註冊專利了），用來防止模型過擬合（overfitting）。

具體來說，先設置一個超參數\(P \in [0, 1]\)，表示按照概率\(P\)隨機將值置\(0\)。
然後假設詞嵌入中某一維分量是\(x\)，按照均勻隨機分佈產生一個隨機數\(r \in [0, 1]\)，然後輸出值\(y\)為：

\[ y = \left\{ \begin{aligned} & \frac{x}{1-P} &, & r > P \\ & 0 &, & r \le P \\ \end{aligned} \right. \]

由於按照概率\(P\)置\(0\)，相當於輸出值的期望變成原來的\((1-P)\)倍，所以再對輸出值除以\((1-P)\)，就可以保持期望不變。

以上操作針對訓練階段，在評估階段，輸出值等於輸入值：

\[y = x \]

嵌入層代碼如下：

代碼

# BERT之嵌入層
class BertEmb(nn.Module):
	def __init__(self, config):
		super().__init__()
		# 標記嵌入，padding_idx=0：編碼為0的嵌入始終為零向量
		self.tok_emb = nn.Embedding(config.vocab_size, config.hidden_size, padding_idx=0)
		# 位置嵌入
		self.pos_emb = nn.Embedding(config.max_position_embeddings, config.hidden_size)
		# 句子位置嵌入
		self.sent_pos_emb = nn.Embedding(config.type_vocab_size, config.hidden_size)

		# 層標準化
		self.layer_norm = nn.LayerNorm(config.hidden_size, eps=config.layer_norm_eps)
		# 隨機失活
		self.dropout = nn.Dropout(config.hidden_dropout_prob)

	def forward(self,
			tok_ids,  # 標記編碼（batch_size * seq_length）
			pos_ids=None,  # 位置編碼（batch_size * seq_length）
			sent_pos_ids=None,  # 句子位置編碼（batch_size * seq_length）
	):
		device = tok_ids.device  # 設備（CPU或CUDA）
		shape = tok_ids.shape  # 形狀（batch_size * seq_length）
		seq_length = shape[1]

		# 默認：[0, 1, ..., seq_length-1]
		if pos_ids is None:
			pos_ids = tc.arange(seq_length, dtype=tc.int64, device=device)
			pos_ids = pos_ids.unsqueeze(0).expand(shape)
		# 默認：[0, 0, ..., 0]，即所有標記都屬於第一個句子
		if sent_pos_ids is None:
			sent_pos_ids = tc.zeros(shape, dtype=tc.int64, device=device)

		# 三種嵌入（batch_size * seq_length * hidden_size）
		tok_embs = self.tok_emb(tok_ids)
		pos_embs = self.pos_emb(pos_ids)
		sent_pos_embs = self.sent_pos_emb(sent_pos_ids)

		# 三種嵌入相加
		embs = tok_embs + pos_embs + sent_pos_embs
		# 層標準化嵌入
		embs = self.layer_norm(embs)
		# 隨機失活嵌入
		embs = self.dropout(embs)
		return embs  # 嵌入（batch_size * seq_length * hidden_size）

其中，
config是BERT的配置文件對象，裏面記錄了各種預先設定的超參數；
vocab_size是詞彙表大小；
hidden_size是詞嵌入長度，默認是768（bert-base-*）或1024（bert-large-*）；
max_position_embeddings是允許的最大標記位置，默認是512；
type_vocab_size是允許的最大句子位置，即最多能輸入的句子數量，默認是2；
layer_norm_eps是一個>0並很接近0的小數\(\epsilon\)，用來防止計算時發生除0等異常操作；
hidden_dropout_prob是隨機失活概率，默認是0.1；
batch_size是小批的大小，即一個小批里的樣本個數；
seq_length是輸入的編碼向量的長度。

1.3、編碼器

編碼器的作用是對嵌入層輸出的隱狀態進行非線性表示，提取出其中的特徵（feature），它是由num_hidden_layers個結構相同（超參數相同）但參數不同（不共享參數）的隱藏層串連構成的。
如圖：

1.3.1、隱藏層

隱藏層包括線性變換、激活函數（activation function）、多頭自注意力（multi-head self-attention）、跳躍連接（skip connection），以及上面介紹過的層標準化和隨機失活。
如圖：

其中，激活函數默認是GELU，線性變換均是逐位置線性變換，即對不同樣本不同位置的詞嵌入應用相同的線性變換（類似於CV&DL領域的\(1 \times 1\)卷積）。

1.3.1.1、線性變換

線性變換在CV&DL領域也叫全連接層（fully connected layer），即

\[y = x W^T + b \]

其中，\(x\)（\(A\)）是輸入向量，\(y\)（\(B\)）是輸出向量，\(W\)（\(B \times A\)）是權重（weight）矩陣，\(b\)（\(B\)）是偏置（bias）向量；\(W\)和\(b\)是學習得到的參數。

另外，嚴格來說，當\(b = \vec 0\)時，上式為線性變換；當\(b \ne \vec 0\)時，上式為仿射變換（affine transformation）。
但是在DL中，人們往往並不那麼摳字眼，對於這兩種變換，一般都簡單地稱為線性變換。

1.3.1.2、激活函數

激活函數在DL中非常關鍵！
因為如果要提高一個神經網絡（neural network）的表示能力，往往需要加深網絡的深度。
然而如果只疊加多個線性變換的話，這等價於一個線性變換（大家可以推推看）！
所以只有在線性變換後接一個非線性變換（nonlinear transformation），即激活函數，才能逐漸加深網絡並提高表示能力。

激活函數有很多，常見的包括sigmoid、tanh、softmax、ReLU、GELU、Swish、Mish等。
本文只講和BERT相關的激活函數：tanh、softmax、GELU。

1.3.1.2.1、tanh

激活函數的一個功能是調整輸入值的取值範圍。
tanh即雙曲正切函數，可以將\((-\infty, +\infty)\)的數映射到\((-1, 1)\)，並且嚴格單調。
函數圖像如圖：

tanh在NLP&DL領域用得比較多。

1.3.1.2.2、softmax

softmax顧名思義，它可以對輸入的一組數值根據其大小給出每個數值的概率，數值越大，概率越高，且概率求和為\(1\)。

假設輸入\(x_k\)，\(k = 0, 1, …, (N-1)\)，則輸出值\(y_k\)為：

\[y_k = \frac{exp(x_k)}{\sum_{i=0}^{N-1} exp(x_i)} \]

實際上，對於任意一個對數幾率（logit）\(x \in (-\infty, +\infty)\)，\(x\)越大，表示某個事件發生的可能性越大，softmax可以將其轉化為概率，即將取值範圍映射到\((0, 1)\)。

1.3.1.2.3、GELU

GELU（Gaussian Error Linear Units）是2016年6月提出的一個激活函數。
GELU相比ReLU曲線更為光滑，允許梯度更好地傳播。
GELU的想法類似於隨機失活，隨機失活是按照0-1分佈，又叫兩點分佈，也叫伯努利分佈（Bernoulli distribution），隨機通過輸入值；而GELU則是將這個概率分佈改成正態分佈（Normal distribution），也叫高斯分佈（Gaussian distribution），然後輸出期望。

假設輸入值是\(x\)，輸出值是\(y\)，那麼GELU就是：

\[y = x P(X \le x) \]

其中，\(X \sim \mathcal{N}(0, 1)\)，\(P\)為概率。

GELU的函數圖像如圖：

其中藍線為ReLU函數圖像，橙線為GELU函數圖像。

1.3.1.3、多頭自注意力

多頭自注意力是Transformer的一大特色。
多頭自注意力的名字可以分成三個詞：多頭、自、注意力：

• 注意力：是DL領域近年來最重要的創新之一！可以使模型以不同的方式對待不同的輸入（即分配不同的權重），而無視空間（即輸入向量排成線形、面形、樹形、圖形等拓撲結構）的形狀、大小、距離。
• 自：是在普通的注意力基礎上修改而來的，可以表示輸入與自身的依賴關係。
• 多頭：是對注意力中涉及的向量分別拆分計算，從而提高表示能力。

對於一般的多頭注意力，假設計算\(x\)（\(H\)）對\(y_i\)（\(H\)），\(i = 0, 1, …, (L-1)\)，的多頭注意力，則首先計算\(q\)（H）、\(k_i\)（H）、\(v_i\)（H）：

\[ q = x W_q^T + b_q \\ k_i = y_i W_k^T + b_k \\ v_i = y_i W_v^T + b_v \\ \]

其中，\(W_z\)（\(H \times H\)）和\(b_z\)（\(H\)）分別為權重矩陣和偏置向量，\(z \in \{ q, k, v \}\)。
然後將這三種向量等長度拆分成\(S\)個向量，稱為頭向量：

\[ q_j = [q_0; q_1; …; q_{S-1}] \\ k_{ij} = [k_{i0}; k_{i1}; …; k_{i, S-1}] \\ v_{ij} = [v_{i0}; v_{i1}; …; v_{i, S-1}] \\ \]

上式中的分號為串連操作，即把多個向量拼接起來組成一個更長的向量。
其中，每個頭向量長度都為\(D\)，且\(S \times D = H\)。

然後計算\(q_j\)對\(k_{ij}\)的注意力分數\(s_{ij}\)：

\[s_{ij} = \frac{q_j k_{ij}^T}{\sqrt{D}} \]

之後可以添加註意力掩碼（也可以不加），即令\(s_{mj} = -\infty\)，\(m\)是需要添加掩碼的位置。
然後通過softmax計算注意力概率\(p_{ij}\)：

\[p_{ij} = \frac{exp(s_{ij})}{\sum_{t=0}^{L-1} exp(s_{tj})} \]

之後對注意力概率進行隨機失活：

\[\hat{p}_{ij} = dropout(p_{ij}) \]

再之後計算輸出向量\(r_j\)（\(D\)）：

\[r_j = \sum_{i=0}^{L-1} \hat{p}_{ij} v_{ij} \]

最終的輸出向量是把每一頭的輸出向量串連起來：

\[r = [r_0; r_1; …; r_{S-1}] \]

其中\(r\)（\(H\)）為最終的輸出向量。

如果令\(x = y_n\)，\(n \in \{ 0, 1, …, L-1 \}\)，即\(x\)是\(y_i\)中的某一個向量，那麼多頭注意力就變為多頭自注意力。

代碼如下：

代碼

# BERT之多頭自注意力
class BertMultiHeadSelfAtt(nn.Module):
	def __init__(self, config):
		super().__init__()
		# 注意力頭數
		self.num_heads = config.num_attention_heads
		# 注意力頭向量長度
		self.head_size = config.hidden_size // config.num_attention_heads

		self.query = nn.Linear(config.hidden_size, config.hidden_size)
		self.key = nn.Linear(config.hidden_size, config.hidden_size)
		self.value = nn.Linear(config.hidden_size, config.hidden_size)

		self.dropout = nn.Dropout(config.attention_probs_dropout_prob)

	# 輸入（batch_size * seq_length * hidden_size）
	# 輸出（batch_size * num_heads * seq_length * head_size）
	def shape(self, x):
		shape = (*x.shape[:2], self.num_heads, self.head_size)
		return x.view(*shape).transpose(1, 2)
	# 輸入（batch_size * num_heads * seq_length * head_size）
	# 輸出（batch_size * seq_length * hidden_size）
	def unshape(self, x):
		x = x.transpose(1, 2).contiguous()
		return x.view(*x.shape[:2], -1)

	def forward(self,
			inputs,  # 輸入（batch_size * seq_length * hidden_size）
			att_masks=None,  # 注意力掩碼（batch_size * seq_length * hidden_size）
	):
		mixed_querys = self.query(inputs)
		mixed_keys = self.key(inputs)
		mixed_values = self.value(inputs)

		querys = self.shape(mixed_querys)
		keys = self.shape(mixed_keys)
		values = self.shape(mixed_values)

		# 注意力分數（batch_size * num_heads * seq_length * seq_length）
		att_scores = querys.matmul(keys.transpose(2, 3))
		# 縮放注意力分數
		att_scores = att_scores / sqrt(self.head_size)
		# 添加註意力掩碼
		if att_masks is not None:
			att_scores = att_scores + att_masks

		# 注意力概率（batch_size * num_heads * seq_length * seq_length）
		att_probs = att_scores.softmax(dim=-1)
		# 隨機失活注意力概率
		att_probs = self.dropout(att_probs)

		# 輸出（batch_size * num_heads * seq_length * head_size）
		outputs = att_probs.matmul(values)
		outputs = self.unshape(outputs)
		return outputs  # 輸出（batch_size * seq_length * hidden_size）

其中，
num_attention_heads是注意力頭數，默認是12（bert-base-*）或16（bert-large-*）；
attention_probs_dropout_prob是注意力概率的隨機失活概率，默認是0.1。

1.3.1.4、跳躍連接

跳躍連接也是DL領域近年來最重要的創新之一！
跳躍連接也叫殘差連接（residual connection）。
一般來說，傳統的神經網絡往往是一層接一層串連而成，前一層輸出作為後一層輸入。
而跳躍連接則是某一層的輸出，跳過若干層，直接輸入某個更深的層。
例如BERT的每個隱藏層中有兩個跳躍連接。

跳躍連接的作用是防止神經網絡梯度消失或梯度爆炸，使損失曲面（loss surface）更平滑，從而使模型更容易訓練，使神經網絡可以設置得更深。

按我個人的理解，一般來說，線性變換是最能保持輸入信息的，而非線性變換則往往會損失一部分信息，但是為了網絡的表示能力不得不線性變換與非線性變換多次堆疊，這樣網絡深層接收到的信息與最初輸入的信息比可能已經面目全非，而跳躍連接則可以讓輸入信息原汁原味地傳播得更深。

隱藏層代碼如下：

代碼

# BERT之隱藏層
class BertLayer(nn.Module):
	# noinspection PyUnresolvedReferences
	def __init__(self, config):
		super().__init__()
		# 多頭自注意力
		self.multi_head_self_att = BertMultiHeadSelfAtt(config)

		self.linear = nn.Linear(config.hidden_size, config.hidden_size)
		self.dropout = nn.Dropout(config.hidden_dropout_prob)
		self.layer_norm = nn.LayerNorm(config.hidden_size, eps=config.layer_norm_eps)

		# 升維線性變換
		self.linear_1 = nn.Linear(config.hidden_size, config.intermediate_size)
		# 激活函數，默認：GELU
		self.act_fct = F.gelu

		# 降維線性變換，使向量大小保持不變
		self.linear_2 = nn.Linear(config.intermediate_size, config.hidden_size)
		self.dropout_1 = nn.Dropout(config.hidden_dropout_prob)
		self.layer_norm_1 = nn.LayerNorm(config.hidden_size, eps=config.layer_norm_eps)
	def forward(self,
			inputs,  # 輸入（batch_size * seq_length * hidden_size）
			att_masks=None,  # 注意力掩碼（batch_size * seq_length * hidden_size）
	):
		outputs = self.multi_head_self_att(inputs, att_masks=att_masks)
		outputs = self.linear(outputs)
		outputs = self.dropout(outputs)
		att_outputs = self.layer_norm(outputs + inputs)  # 跳躍連接

		outputs = self.linear_1(att_outputs)
		outputs = self.act_fct(outputs)

		outputs = self.linear_2(outputs)
		outputs = self.dropout_1(outputs)
		outputs = self.layer_norm_1(outputs + att_outputs)  # 跳躍連接
		return outputs  # 輸出（batch_size * seq_length * hidden_size）

其中，
intermediate_size是中間一個升維線性變換升維后的長度，默認是3072（bert-base-*）或4096（bert-large-*）。

編碼器代碼如下：

代碼

# BERT之編碼器
class BertEnc(nn.Module):
	def __init__(self, config):
		super().__init__()
		# num_hidden_layers個隱藏層
		self.layers = nn.ModuleList([BertLayer(config)
			for _ in range(config.num_hidden_layers)])
	# noinspection PyTypeChecker
	def forward(self,
			inputs,  # 輸入（batch_size * seq_length * hidden_size）
			att_masks=None,  # 注意力掩碼（batch_size * seq_length）
	):
		# 調整注意力掩碼的值和形狀
		if att_masks is not None:
			device = inputs.device  # 設備（CPU或CUDA）
			dtype = inputs.dtype  # 數據類型（float16、float32或float64）
			shape = att_masks.shape  # 形狀（batch_size * seq_length）
			t = tc.zeros(shape, dtype=dtype, device=device)
			t[att_masks<=0] = -inf  # exp(-inf) = 0
			t = t[:, None, None, :]
			att_masks = t

		outputs = inputs
		for layer in self.layers:
			outputs = layer(outputs, att_masks=att_masks)
		return outputs  # 輸出（batch_size * seq_length * hidden_size）

其中，
num_hidden_layers是隱藏層數量，默認是12（bert-base-*）或24（bert-large-*）。

1.4、池化層

池化層是將[CLS]標記對應的表示取出來，並做一定的變換，作為整個序列的表示並返回，以及原封不動地返回所有的標記表示。
如圖：

其中，激活函數默認是tanh。

池化層代碼如下：

代碼

# BERT之池化層
class BertPool(nn.Module):
	def __init__(self, config):
		super().__init__()
		self.linear = nn.Linear(config.hidden_size, config.hidden_size)
		self.act_fct = F.tanh
	def forward(self,
			inputs,  # 輸入（batch_size * seq_length * hidden_size）
	):
		# 取[CLS]標記的表示
		outputs = inputs[:, 0]
		outputs = self.linear(outputs)
		outputs = self.act_fct(outputs)
		return outputs  # 輸出（batch_size * hidden_size）

1.5、輸出

主模型最後輸出所有的標記表示和整體的序列表示，分別用於針對每個標記的預測任務和針對整個序列的預測任務。

主模型代碼如下：

代碼

# BERT之預訓練模型抽象基類
class BertPreTrainedModel(PreTrainedModel):
	from transformers import BertConfig
	from transformers import BERT_PRETRAINED_MODEL_ARCHIVE_MAP
	from transformers import load_tf_weights_in_bert

	config_class = BertConfig
	pretrained_model_archive_map = BERT_PRETRAINED_MODEL_ARCHIVE_MAP
	load_tf_weights = load_tf_weights_in_bert
	base_model_prefix = 'bert'

	# 注意力頭剪枝
	def _prune_heads(self, heads_to_prune):
		pass
	# 參數初始化
	def _init_weights(self, module):
		config = self.config
		f = lambda x: x is not None and x.requires_grad
		if isinstance(module, nn.Embedding):
			if f(module.weight):
				# 正態分佈隨機初始化
				module.weight.data.normal_(mean=0.0, std=config.initializer_range)
		elif isinstance(module, nn.Linear):
			if f(module.weight):
				# 正態分佈隨機初始化
				module.weight.data.normal_(mean=0.0, std=config.initializer_range)
			if f(module.bias):
				# 初始為0
				module.bias.data.zero_()
		elif isinstance(module, nn.LayerNorm):
			if f(module.weight):
				# 初始為1
				module.weight.data.fill_(1.0)
			if f(module.bias):
				# 初始為0
				module.bias.data.zero_()
# BERT之主模型
class BertModel(BertPreTrainedModel):
	def __init__(self, config):
		super().__init__(config)
		self.config = config
		# 嵌入層
		self.emb = BertEmb(config)
		# 編碼器
		self.enc = BertEnc(config)
		# 池化層
		self.pool = BertPool(config)
		# 參數初始化
		self.init_weights()

	# noinspection PyUnresolvedReferences
	def get_input_embeddings(self):
		return self.emb.tok_emb
	def set_input_embeddings(self, embs):
		self.emb.tok_emb = embs

	def forward(self,
			tok_ids,  # 標記編碼（batch_size * seq_length）
			pos_ids=None,  # 位置編碼（batch_size * seq_length）
			sent_pos_ids=None,  # 句子位置編碼（batch_size * seq_length）
			att_masks=None,  # 注意力掩碼（batch_size * seq_length）
	):
		outputs = self.emb(tok_ids, pos_ids=pos_ids, sent_pos_ids=sent_pos_ids)
		outputs = self.enc(outputs, att_masks=att_masks)
		pooled_outputs = self.pool(outputs)
		return (
			outputs,  # 輸出（batch_size * seq_length * hidden_size）
			pooled_outputs,  # 池化輸出（batch_size * hidden_size）
		)

其中，
BertPreTrainedModel是預訓練模型抽象基類，用於完成一些初始化工作。

後記

本文詳細地介紹了BERT主模型的結構及其組件，了解它的構造以及代碼實現對於理解以及應用BERT有非常大的幫助。
後續兩篇文章會分別介紹BERT預訓練和下游任務相關。

從BERT主模型的結構中，我們可以發現，BERT拋棄了RNN架構，而只用注意力機制來抽取長距離依賴（這個其實是Transformer架構的特點）。
由於注意力可以并行計算，而RNN必須串行計算，這就使得模型計算效率大大提升，於是BERT這類模型也能夠堆得很深。
BERT為了能夠同時做單句和雙句的序列和標記的預測任務，設計了[CLS]和[SEP]等特殊標記分別作為序列表示以及標記不同的句子邊界，整體採用了桶狀的模型結構，即輸入時隱狀態的形狀與輸出時隱狀態的形狀相等（只是在每個隱藏層有升維與降維操作，整體上詞嵌入長度保持不變）。
由於注意力機制對距離不敏感，所以BERT額外添加了位置特徵。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

一、前言

  今年或許是因為疫情的原因吧，感覺時間過的嗖嗖的特別快，不知不覺間2020年已經過去了二分之一，如果把一整年的時間比作我們手機的電量的話，意味着只剩下百分之五十了，不知大家是否心理會有恐慌，在自己手機電量只剩百分之五十的時候，大家是否會找電源來進行充電呢？至少我會，不知大家是否還記得年初定下的目標，是否完成了年度任務的百分之五十？
  六月初的時候，我還在考慮是否要寫一個年中總結，來對我近半年的工作做一個總結，工作中發生的一件事情，讓我覺得還是應該寫這個一篇文章，在每年歲末年初的時候，我都會牽頭來整理我們下一年的年度計劃，然後把年度計劃分解到每個月，在制定月計劃的時候，結合年度計劃及當前實際情況，制定當月的月度計劃，每月統計所有人員月度工作完成情況，以此作為年底考核的一個指標，考核的目的是為了更好的完成工作，既然是為了完成年度目標，那麼在每月初、每季度初大家在制定計劃的時候，就需要看看計劃是否合理、是否合適必要、任務的輕重緩急安排的是否合適，在每月月末、每季度末的時候，對大家完成情況進行統計，對於延期的要了解原因，是工作是安排的不合理，還是其他主管原因造成的，如果延期，應該採取什麼補救措施等，是否要修訂年度工作計劃或者採取措施，在接下來的工作中進行補救；而不是放任不管，到年底統計大家年度工作完成情況，直接進行考核。這個也是我為什麼要寫一下年中總結的原因。

二、2020年上半年總結

  下面我將從工作、學習、生活三個方面對自己上半年做一個總結，我把2020年的年度目標分別歸類到學習與生活中，2020年目標詳見文章2019年總結與2020年展望，首先來說一下工作吧，如果沒有今年的疫情，按照年初的安排，上半年應該是大量的外出調研及廠商交流，4月低5月初就會啟動今年第一批信息化項目建設，由於疫情原因，6月底第一批信息化項目才會啟動進行建設；在接下來的半年中會有兩批信息化項目啟動建設；項目建設壓力還是挺重的；工作中的另外一部分就是自己的日常工作安排，這部分工作比去年有所進步，但是還有較大的進步空間，主要的問題就是工作的先後順序、輕重緩急安排的不合理，對自己的工作應該有側重點，而不是全部平均用力，另外一個就是工作中總結寫的比較少，這部分在下半年需要重點關注了，同時接下來我也會單獨寫一篇文章，對自己上邊工作的心得體會做一個總結，對上半年事務性工作部分進行梳理；其次來說說學習，截止目前，讀書六本，分別是阮一峰的《前方的路》、《來世界的倖存者》、《中台戰略》、《數據中台》、《麥肯錫教我的邏輯思維》、《團隊管理》，整理讀書筆記2篇，分別是前方的路、未來時間的倖存者；按照年度制定的計劃，平均每月最少寫兩篇文章，截止目前，共寫了八篇，還差四篇；項目管理師證書由於疫情原因，上半年的考試取消了，合併到下半年，11月7日、11月8日舉行考試，這個從下半年8月開始準備，一次性考過，不給自己找任何不努力的接口，鯤鵬認證開發工程師由於自己對未來職業的規劃調整，暫時不在考取，軟件開發平台的重構，由於上半年工作安排的太滿及對未來職業的規劃，接下來不在會當做一個主要工作來進行升級，有一個需要改進的地方，就是對手機的依賴太嚴重，短視頻、短新聞佔據了自己大量學習與獨立思考的時間，這個應該就是我們這個年代所面臨的誘惑吧，最後來說一下生活，上半年購買了自己人生的第一輛車，雖說不是豪車，但是是通過自己的努力奮鬥得來的，還是挺欣慰的，周末的時候可以帶着家人到郊區轉轉，確實給生活帶來了諸多便利，年初定計劃的時候說要帶自己的家人出去旅遊1~2次，由於疫情原因，看來要泡湯了，不過可以改為近郊自駕游，在疫情緩解之後再考慮旅遊的地方吧；另外一個受影響比較大的就是自己喜愛的游泳了，不得不暫停，但減肥計劃，依舊不變，今年減肥目標不變，減肥至少15斤，減肥是最考驗一個人自律，我一定會通過減肥，證明自己是一個自律能力強的人，證明自己我可以。

三、結語

  到現在為止，我越來越認為優秀是一種習慣，這也就解釋了為什麼好多優秀的人在這一行業可以做到很好，換到其他行業同樣也可以做的很好，一個人之所以優秀，是因為他有良好的行為習慣、生活習慣，其中包括對時間的安排、解決問題的思路及方法、對待新事物的態度、思考問題的方式方法及相應的學習方法論；同時我也越來越相信性格決定命運，一個人的性格在很大程度上決定了在面對某一件事情的時候會採取的行動，我們在這個社會上都不是孤立存在的，我們一定會與這個社會產生交互，只要產生交互，別人就會依據你的性格、個性、習慣來給你做畫像，做人設，不可避免的會影響到我們未來的發展；
  我們的現狀是過去努力的結果，如果我們對自己的現狀不太滿意，那或許是因為過去你不夠努力或者方向不對吧，要想儘快達到令自己滿意的狀態，應該馬上從力所能級的事情開始做起，就如同我寫的這篇總結一樣，是對我過去半年工作的復盤、反思及總結，我相信人生沒有徒勞的努力，總有一天他會間接或者直接地助你一臂之力。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧