了解一点儿 spring javaConfig

曾几何时,我们看到的架构书籍,都是在说代码要和配置分离,让配置使用xml,ini,properties之类的。然并卵!现在,spring cloud社区又回到原点,推荐使用java代码方式写配置了。

不多说这些,所谓的技术选型方案,也不过是取舍。spring boot是spring cloud的基础,spring是spring boot的基础,而推荐的配置方式是javaConfig,所以,我们还是简单了解一下怎么用吧。

最早的xml配置方式:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="userService" class="com.wzz.study.service.UserService"></bean>
</beans>

对应javaConfig形式:

@Configuration
public class ApplicationConfig {
    @Bean
    public UserService userService() {
        return new UserService();
    }
}

标注了@Configuration的类,代表其是一个javaConfig配置类。@Bean实现bean定义注册到spring ioc容器。

spring javaConfig还有其他一些复杂的配置,但我这不想写了,直接看文档吧。

https://docs.spring.io/spring/docs/5.1.3.RELEASE/spring-framework-reference/core.html#beans-java

spring cloud 版本规则

第一次看spring cloud的版本命名,感觉很莫名其妙。spring Cloud是一个由很多子项目组成的一个大型项目,原则上都有自己的发布版本。为了要管理每个版本的子项目清单,所以命名没有采用版本号的方式,而是通过命名的方式,以避免版本名与子项目的发布号混淆。

version.jpg

 

大版本

看上图,他不是采用xx.xx.xx.RELEASE这样的熟悉的数字版本号命名。而是采而是对应一个开发代号,比如Dalston,Edgware等,版本名称采用了伦敦地铁站的名字。这些是有规律的,首字母从A开始,B,C,D,现在是F了。

小版本

Spring Cloud 小版本分为:

SNAPSHOT: 快照版本,随时可能修改

M: MileStone,M1表示第1个里程碑版本,一般同时标注PRE,表示预览版版。

SR: Service Release,SR1表示第1个正式版本,一般同时标注GA:(GenerallyAvailable),表示稳定版本。

一般,我们生产环境选择SR版本。

 

总结:spring cloud采用版本命,首字母按A到Z递增。小修改,在更新对应的M,或SR后缀,如M1,SR2。我们选SR版本就可以了。

spring cloud (1) 开篇

本文主要涉及了微服务的基本概念,以及简要说明下spring cloud主要由那几样东西构成。

很久没有写东西,有点方。但写什么呢,要找的网上都有啊(这个懒人借口不错)。

近来研究上了spring cloud,所以,往后一段时间,就写一系列spring cloud的内容吧。当学习笔记了。

 

PART 1

先说一下单体服务到微服务的进化史。

记得最开始学做网站,都是一个war包,连接数据库。搞掂。这就是所谓最原始的单体应用。甚至war和数据库都是放在同一台服务器上。架构图是这样的:

1.jpg

随着用户的增长,网站负载很高。一台服务器扛不住啊。老哥DB,麻烦您用另外的服务器单独跑吧,这样我们不用再一台小机箱里面挤来挤去啊。好,优化下架构,又可以抗一会儿了。

2.jpg

业务很好,而且越来越多人了,整条村的人每天要访问我们的网站,服务器快扛不住了,怎么办啊,继续加机器呗。读写分离。一个主库+N多个从库。架构变成这样了。

3.jpg

好景不长,没过多久,用户量又要翻倍了,这下单台webapp不行了,好拆分业务,弄成多个web服务。

4.jpg

这下是稳稳地了。遇到压力就拆分,一点问题都没有。。。

一段时间后,各个应用,各个db竟然加起来有上百个之多。新人进来,简直要抓狂,而且服务的相互调用也乱成一锅粥了。

5.jpg

这种时候,怎么办?

肯定是删库跑路啊。谁留谁傻逼。

等等。。。。为啥不试试微服务呢?说不定还能抢救一下呢?

6.jpg

PART 2

然后,讲一下为啥要用spring cloud。项目越来越多,相互依赖越来越严重。通过http调用的方式已经要让人崩溃了。这时,spring cloud,这个微服务全家桶可以来拯救宇宙了。整理一下,spring cloud主要有以下内容:服务治理、分布式配置、分布式调度、调用跟踪等内容。我打算接下来,要写的也主要是这些:

1.spring bean 代码配置基础

2.spring boot基础

3.spring cloud eureka

4.spring cloud Ribbon

5.spring cloud Hystrix

6. spring cloud Feign

7.Spring Cloud Zuul

9.Spring Cloud Config

7.jpg

大医精诚

凡大医治病,必当安神定志,无欲无求,先发大慈恻隐之心,誓愿普救含灵之苦。若有疾厄来求救者,不得问其贵贱贫富,长幼妍媸,怨亲善友,华夷愚智,普同一等,皆如至亲之想,亦不得瞻前顾后,自虑吉凶,护惜身命。见彼苦恼,若己有之,深心凄怆,勿避险巇、昼夜夜寒暑、饥渴疲劳,一心赴救,无作功夫形迹之心。如此可为苍生大医,反此则是含灵巨贼。自古名贤治病,多用生命以济危急,虽曰贱畜贵人,至於爱命,人畜一也。捐彼益已,物情同患,况於人乎!夫杀生求生、去生更远。吾今此方所以不用生命为药者,良由此也。其 虫、水蛭之属,市有先死者,则市而用之,不在此例。只如鸡卵一物,以其混沌未分,必有大段要急之处,不得已隐忍而用之。能不用者,斯为大哲,亦所不及也。其有患疮痍、下痢,臭积不可瞻视,人所恶见者,但发惭愧凄怜忧恤之意,不得起一念蒂芥之心,是吾之志也。
夫大医之体,欲得澄神内视。望之俨然,宽裕汪汪,不皎不昧。省病诊疾,至意深心,详察形候,织毫勿失,处判针药,无得参差。虽曰病宜速救,要须临事不惑,唯当审谛覃思,不得於性命之上,率而自逞俊快,邀射名誉,甚不仁矣!又到病家,纵绮羁满目,勿左右顾眄,丝竹凑耳,无得似有所娱,珍羞叠焉,食如无味,醽醁兼陈,看有若无。所以尔者,夫壹人向隅,满堂不乐,而况病人苦楚,不离斯须,而医者安然欢娱,傲然自得,兹乃人神之所共耻,至人之所不为,斯盖医之本意也。
夫为医之法,不得多语调笑,谈谑喧哗,道说是非,议论人物,炫耀声名,訾毁诸医,自矜已德,偶然治差一病,则昂头戴面,而有自许之貌,谓天下无双,此医人之膏肓也。
所以医人不得恃己所长,专心经略财物,但作救苦之心,於冥运道中③,自感多福者耳。又不得以彼富贵,处以珍贵之药,令彼难求,自卫功能,谅非忠恕之道。志存救济,故亦曲碎论之,学者不可耻言之鄙俚也。

伤寒论序

论曰:余每览越人入虢之诊,望齐侯之色,未尝不慨然叹其才秀也。
皮之不存,毛将安附焉?卒然遭邪风之气,婴非常之疾,患及祸至,而方震栗;降志屈节,钦望巫祝,告穷归天,束手受败。赍百年之寿命,持至贵之重器,委付凡医,恣其所措。咄嗟呜呼!厥身已毙,神明消灭,变为异物,幽潜重泉,徒为啼泣。痛夫!举世昏迷,莫能觉悟,不惜其命。若是轻生,彼何荣势之云哉?而进不能爱人知人,退不能爱身知己,遇灾值祸,身居厄地,蒙蒙昧昧,憃若游魂。哀乎!趋世之士,驰竞浮华,不固根本,忘躯徇物,危若冰谷,至于是也!余宗族素多,向余二百。建安纪年以来,犹未十稔,其死亡者,三分有二,伤寒十居其七。感往昔之沦丧,伤横夭之莫救,乃勤求古训,博采众方,撰用《素问》、《九卷》、《八十一难》、《阴阳大论》、《胎胪药录》,并《平脉辨证》,为《伤寒杂病论》合十六卷,虽未能尽愈诸病,庶可以见病知源,若能寻余所集,思过半矣。
夫天布五行,以运万类,人禀五常,以有五藏,经络府俞,阴阳会通,玄冥幽微,变化难极,自非才高识妙,岂能探其理致哉?上古有神农、黄帝、岐伯、伯高、雷公、少俞、少师、仲文,中世有长桑、扁鹊,汉有公乘阳庆及仓公,下此以往,未之闻也。观今之医,不念思求经旨,以演其所知,各承家技,始终顺旧。省疾问病,务在口给,相对斯须,便处汤药,按寸不及尺,握手不及足,人迎、趺阳,三部不参,动数发息,不满五十,短期未知决诊,九候曾无仿佛,明堂阙庭,尽不见察,所谓窥管而已。夫欲视死别生,实为难矣!
孔子云:生而知之者上。学则亚之。多闻博识,知之次也。余宿尚方术,请事斯语。