Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction

出现之后查看相应的线程

命令：select * from information_schema.innodb_trx

找到对应的线程之后kill了，就ok!

场景：因为使用了netstat -p参数。

权限问题，zabbix_agentd是zabbix用户启动的，默认不能执行netstat -p等命令，导致从服务器取到的自动发现脚本为空

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
解决方法 ：
chmod +s /bin/netstat

chmod +s 是什么意思

再次执行就会消失（变成正常）

     前提条件是cobbler得安装完成，并且咱们提前写好ks文件，生成profile等等。接下来就是咱们运维平台，根据获取的MAC地址给服务器定义一个IP信息录入，然后定制安装操作系统即可：

第一步：添加主机分配IP，最主要是MAC地址：

第二步：默认刚开始添加的适合都是等待装机状态，当点击开始装机时候，后台根据MAC地址定义操作系统的profile和生成IP地址，这个时候装机状态就变成装机中，然后开启服务器电源执行装机即可：

第三步：启动虚拟机开始装机：

到此安装完成；装机状态可变成装机完成，这里实现的思路咱们可以这样，写一个脚本久不久去ping 这个刚刚分配的IP地址，等真正可以Ping通之后，可以向这个IP发送某条命令然后根据返回值就能判断是否已经完成装机操作。

不足，这里我没有运用ipmi的一些机制来完成，后面慢慢学习和补充，最后咱们跑一个初始化脚本，然后把生产的机器的资产信息，同步到咱们CMDB平台即可。

定制操作系统可以参考官方文档的system修改成如下的操作：

1、检出
svn  co  http://路径(目录或文件的全路径)　[本地目录全路径] --username 用户名 --password 密码

svn  co  svn://路径(目录或文件的全路径)　[本地目录全路径]  --username 用户名 --password 密码
svn  checkout  http://路径(目录或文件的全路径)　[本地目录全路径] --username　用户名
svn  checkout  svn://路径(目录或文件的全路径)　[本地目录全路径]  --username　用户名
注：如果不带--password 参数传输密码的话，会提示输入密码，建议不要用明文的--password 选项。
　　其中 username 与 password前是两个短线，不是一个。
　　不指定本地目录全路径，则检出到当前目录下。
例子：
svn co svn://localhost/测试工具 /home/testtools --username wzhnsc
svn co http://localhost/test/testapp --username wzhnsc
svn checkout svn://localhost/测试工具 /home/testtools --username wzhnsc
svn checkouthttp://localhost/test/testapp --username wzhnsc

2、导出(导出一个干净的不带.svn文件夹的目录树)
svn  export  [-r 版本号]  http://路径(目录或文件的全路径) [本地目录全路径]　--username　用户名
svn  export  [-r 版本号]  svn://路径(目录或文件的全路径) [本地目录全路径]　--username　用户名
svn  export  本地检出的(即带有.svn文件夹的)目录全路径  要导出的本地目录全路径
注：第一种从版本库导出干净工作目录树的形式是指定URL，
　　　如果指定了修订版本号，会导出相应的版本，
　　　如果没有指定修订版本，则会导出最新的，导出到指定位置。
　　　如果省略 本地目录全路径，URL的最后一部分会作为本地目录的名字。
　　第二种形式是指定 本地检出的目录全路径 到 要导出的本地目录全路径，所有的本地修改将会保留，
　　　但是不在版本控制下(即没提交的新文件，因为.svn文件夹里没有与之相关的信息记录)的文件不会拷贝。
例子：
svn export svn://localhost/测试工具 /home/testtools --username wzhnsc
svn export svn://localhost/test/testapp --username wzhnsc
svn export /home/testapp /home/testtools

3、添加新文件 
svn　add　文件名
注：告诉SVN服务器要添加文件了，还要用svn commint -m真实的上传上去！
例子：
svn add test.php ＜－ 添加test.php 
svn commit -m “添加我的测试用test.php“ test.php
svn add *.php ＜－ 添加当前目录下所有的php文件
svn commit -m “添加我的测试用全部php文件“ *.php

4、提交
svn　commit　-m　“提交备注信息文本“　[-N]　[--no-unlock]　文件名
svn　ci　-m　“提交备注信息文本“　[-N]　[--no-unlock]　文件名
必须带上-m参数，参数可以为空，但是必须写上-m
例子：
svn commit -m “提交当前目录下的全部在版本控制下的文件“ * ＜－ 注意这个*表示全部文件
svn commit -m “提交我的测试用test.php“ test.php
svn commit -m “提交我的测试用test.php“ -N --no-unlock test.php ＜－ 保持锁就用–no-unlock开关
svn ci -m “提交当前目录下的全部在版本控制下的文件“ * ＜－ 注意这个*表示全部文件
svn ci -m “提交我的测试用test.php“ test.php
svn ci -m “提交我的测试用test.php“ -N --no-unlock test.php ＜－ 保持锁就用–no-unlock开关

5、更新文件
svn　update
svn　update　-r　修正版本　文件名
svn　update　文件名
例子：
svn update ＜－ 后面没有目录，默认将当前目录以及子目录下的所有文件都更新到最新版本
svn update -r 200 test.cpp ＜－ 将版本库中的文件 test.cpp 还原到修正版本（revision）200
svn update test.php ＜－ 更新与版本库同步。
　　　　　　　　　　　 提交的时候提示过期冲突，需要先 update 修改文件，
　　　　　　　　　　　 然后清除svn resolved，最后再提交commit。

6、删除文件
svn　delete　svn://路径(目录或文件的全路径) -m “删除备注信息文本”
推荐如下操作：
svn　delete　文件名 
svn　ci　-m　“删除备注信息文本”
例子：
svn delete svn://localhost/testapp/test.php -m “删除测试文件test.php”
推荐如下操作：
svn delete test.php 
svn ci -m “删除测试文件test.php”

７、加锁/解锁 
svn　lock　-m　“加锁备注信息文本“　[--force]　文件名 
svn　unlock　文件名
例子：
svn lock -m “锁信测试用test.php文件“ test.php 
svn unlock test.php

8、比较差异 
svn　diff　文件名 
svn　diff　-r　修正版本号m:修正版本号n　文件名
例子：
svn diff test.php＜－ 将修改的文件与基础版本比较
svn diff -r 200:201 test.php＜－ 对 修正版本号200 和 修正版本号201 比较差异

9、查看文件或者目录状态
svn st 目录路径/名
svn status 目录路径/名＜－ 目录下的文件和子目录的状态，正常状态不显示 
　　　　　　　　　　　　　【?：不在svn的控制中；  M：内容被修改；C：发生冲突；
　　　　　　　　　　　　　　A：预定加入到版本库；K：被锁定】 
svn  -v 目录路径/名
svn status -v 目录路径/名＜－ 显示文件和子目录状态
　　　　　　　　　　　　　　【第一列保持相同，第二列显示工作版本号，
　　　　　　　　　　　　　　　第三和第四列显示最后一次修改的版本号和修改人】 
注：svn status、svn diff和 svn revert这三条命令在没有网络的情况下也可以执行的，
　　原因是svn在本地的.svn中保留了本地版本的原始拷贝。 

10、查看日志
svn　log　文件名
例子：
svn log test.php＜－ 显示这个文件的所有修改记录，及其版本号的变化 

11、查看文件详细信息
svn　info　文件名
例子：
svn info test.php

12、SVN 帮助
svn　help ＜－ 全部功能选项
svn　help　ci ＜－ 具体功能的说明

13、查看版本库下的文件和目录列表 
svn　list　svn://路径(目录或文件的全路径)
svn　ls　svn://路径(目录或文件的全路径)
例子：
svn list svn://localhost/test
svn ls svn://localhost/test ＜－ 显示svn://localhost/test目录下的所有属于版本库的文件和目录 

14、创建纳入版本控制下的新目录
svn　mkdir　目录名
svn　mkdir　-m　"新增目录备注文本"　http://目录全路径
例子：
svn mkdir newdir
svn mkdir -m "Making a new dir." svn://localhost/test/newdir 
注：添加完子目录后，一定要回到根目录更新一下，不然在该目录下提交文件会提示“提交失败”
svn update
注：如果手工在checkout出来的目录里创建了一个新文件夹newsubdir，
　　再用svn mkdir newsubdir命令后，SVN会提示：
　　svn: 尝试用 “svn add”或 “svn add --non-recursive”代替？
　　svn: 无法创建目录“hello”: 文件已经存在
　　此时，用如下命令解决：
　　svn add --non-recursive newsubdir
　　在进入这个newsubdir文件夹，用ls -a查看它下面的全部目录与文件，会发现多了：.svn目录
　　再用 svn mkdir -m "添hello功能模块文件" svn://localhost/test/newdir/newsubdir 命令，
　　SVN提示：
　　svn: File already exists: filesystem '/data/svnroot/test/db', transaction '4541-1',
　　path '/newdir/newsubdir '

15、恢复本地修改 
svn　revert　[--recursive]　文件名
注意: 本子命令不会存取网络，并且会解除冲突的状况。但是它不会恢复被删除的目录。
例子：
svn revert foo.c ＜－ 丢弃对一个文件的修改
svn revert --recursive . ＜－恢复一整个目录的文件，. 为当前目录 

16、把工作拷贝更新到别的URL 
svn　switch　http://目录全路径　本地目录全路径
例子：
svn switch http://localhost/test/456 . ＜－ (原为123的分支)当前所在目录分支到localhost/test/456

17、解决冲突 
svn　resolved　[本地目录全路径]
例子：
$ svn update
C foo.c
Updated to revision 31.
如果你在更新时得到冲突，你的工作拷贝会产生三个新的文件：
$ ls
foo.c
foo.c.mine
foo.c.r30
foo.c.r31
当你解决了foo.c的冲突，并且准备提交，运行svn resolved让你的工作拷贝知道你已经完成了所有事情。
你可以仅仅删除冲突的文件并且提交，但是svn resolved除了删除冲突文件，还修正了一些记录在工作拷贝管理区域的记录数据，所以我们推荐你使用这个命令。

18、不checkout而查看输出特定文件或URL的内容 
svn　cat　http://文件全路径
例子：
svn cat http://localhost/test/readme.txt

19、新建一个分支copy

svn copy branchA branchB  -m "make B branch" // 从branchA拷贝出一个新分支branchB

20、合并内容到分支merge

svn merge branchA branchB  // 把对branchA的修改合并到分支branchB

1.工具下载地址：

Eclipse：http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/neonr

Spring Tool Suite：https://spring.io/tools/sts/all

2.使用版本为：

Eclipse：eclipse-jee-neon-R-win32-x86_64.zip

Spring Tool Suite：springsource-tool-suite-3.8.0.RELEASE-e4.5.2-updatesite.zip

3.安装步骤：

3.1 解压Eclipse，打开Help ---> Install New Sofware...

3.2 点击右上角位置的：Add...

3.3 点击右上角位置的：Loccal...，选中解压之后的springsource-tool-suite-3.8.0.RELEASE-e4.5.2-updatesite，，之后点击 OK

3.4 点击 Select All，之后确认，后面有多次需要确认，会花费一定的时间，请耐心等待，安装完成之后，会提示重启。

小提示：可以选中在线安装Spring Tool Suite 这个插件。Help ---> Eclipse Marketplce...之后搜索spring tool suite

注意版本的选择

查看Eclipse版本：Help ---> About Eclipse

Third-party library upgrades

A number of third party libraries have been upgraded to their latest version. Updates include Jetty 9.3, Tomcat 8.5, Jersey 2.23, Hibernate 5.0, Jackson 2.7, Solr 5.5, Spring Data Hopper, Spring Session 1.2, Hazelcast 3.6, Artemis 1.3, Ehcache 3.1, Elasticsearch 2.3, Spring REST Docs 1.1, Spring AMQP 1.6 & Spring Integration 4.3.

Several Maven plugins were also upgraded.

Couchbase support

Full auto-configuration support is now provided for Couchbase. You can easily access a Bucketand Cluster bean by adding the spring-boot-starter-data-couchbase "Starter" and providing a little configuration:

spring.couchbase.bootstrap-hosts=my-host-1,192.168.1.123
spring.couchbase.bucket.name=my-bucket
spring.couchbase.bucket.password=secret

It’s also possible to use Couchbase as a backing store for a Spring Data Repository or as aCacheManager. Refer to the updated documentation for details.

Neo4J Support

Auto-configuration support is now provided for Neo4J. You can connect to a remote server or run an embedded Neo4J server. You can also use Neo4J to back a Spring Data Repository, for example:

public interface CityRepository extends GraphRepository {    Page findAll(Pageable pageable);    City findByNameAndCountry(String name, String country);}

Full details are provided in the Neo4J section of the reference documentation.

Redis Spring Data repositories

Redis can now be used to back Spring Data repositories. See the Spring Data Redis documentation for more details.

Narayana transaction manager support

Auto-configuration support is now included for the Narayana transaction manager. You can choose between Narayana, Bitronix or Atomkos if you need JTA support. See the updated reference guidefor details.

Caffeine cache support

Auto-configuration is provided for Caffeine v2.2 (a Java 8 rewrite of Guava’s caching support). Existing Guava cache users should consider migrating to Caffeine as Guava cache support will be dropped in a future release.

Elasticsearch Jest support

Spring Boot auto-configures a JestClient and a dedicated HealthIndicator if Jest is on the classpath. This allows you to use Elasticsearch even when spring-data-elasticsearch isn’t on the classpath.

Analysis of startup failures

Spring Boot will now perform analysis of common startup failures and provide useful diagnostic information rather than simply logging an exception and its stack trace. For example, a startup failure due to the embedded servlet container’s port being in use looked like this in earlier versions of Spring Boot:

2016-02-16 17:46:14.334 ERROR 24753 --- [           main] o.s.boot.SpringApplication               : Application startup failedjava.lang.RuntimeException: java.net.BindException: Address already in useat io.undertow.Undertow.start(Undertow.java:181) ~[undertow-core-1.3.14.Final.jar:1.3.14.Final]at org.springframework.boot.context.embedded.undertow.UndertowEmbeddedServletContainer.start(UndertowEmbeddedServletContainer.java:121) ~[spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.startEmbeddedServletContainer(EmbeddedWebApplicationContext.java:293) ~[spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.finishRefresh(EmbeddedWebApplicationContext.java:141) ~[spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:541) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118) ~[spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:766) [spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.SpringApplication.createAndRefreshContext(SpringApplication.java:361) [spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.SpringApplication.run(SpringApplication.java:307) [spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.SpringApplication.run(SpringApplication.java:1191) [spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at org.springframework.boot.SpringApplication.run(SpringApplication.java:1180) [spring-boot-1.3.2.RELEASE.jar:1.3.2.RELEASE]at sample.undertow.SampleUndertowApplication.main(SampleUndertowApplication.java:26) [classes/:na]
Caused by: java.net.BindException: Address already in useat sun.nio.ch.Net.bind0(Native Method) ~[na:1.8.0_60]at sun.nio.ch.Net.bind(Net.java:433) ~[na:1.8.0_60]at sun.nio.ch.Net.bind(Net.java:425) ~[na:1.8.0_60]at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) ~[na:1.8.0_60]at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) ~[na:1.8.0_60]at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:190) ~[xnio-nio-3.3.4.Final.jar:3.3.4.Final]at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243) ~[xnio-api-3.3.4.Final.jar:3.3.4.Final]at io.undertow.Undertow.start(Undertow.java:137) ~[undertow-core-1.3.14.Final.jar:1.3.14.Final]... 11 common frames omitted

In 1.4, it will look like this:

2016-02-16 17:44:49.179 ERROR 24745 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :***************************
APPLICATION FAILED TO START
***************************Description:Embedded servlet container failed to start. Port 8080 was already in use.Action:Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.

If you still want to see the stacktrace of the underlying cause, enable debug logging fororg.springframework.boot.diagnostics.LoggingFailureAnalysisReporter.

Image Banners

You can now use image files to render ASCII art banners. Drop a banner.gif, banner.jpg orbanner.png file into src/main/resources to have it automatically converted to ASCII. You can use the banner.image.width and banner.image.height properties to tweak the size, or usebanner.image.invert to invert the colors.

RestTemplate builder

A new RestTemplateBuilder can be used to easily create a RestTemplate with sensible defaults. By default, the built RestTemplate will attempt to use the most suitable ClientHttpRequestFactoryavailable on the classpath and will be aware of the MessageConverter instances to use (including Jackson). The builder includes a number of useful methods that can be used to quickly configure aRestTemplate. For example, to add BASIC auth support you can use:

@Beanpublic RestTemplate restTemplate(RestTemplateBuilder builder) {    return builder.basicAuthorization("user", "secret").build();
}

The auto-configured TestRestTemplate now uses the RestTemplateBuilder as well.

JSON Components

A new @JsonComponent annotation is now provided for custom Jackson JsonSerializer and/orJsonDeserializer registration. This can be a useful way to decouple JSON serialization logic:

@JsonComponentpublic class Example {    public static class Serializer extends JsonSerializer {        // ...}    public static class Deserializer extends JsonDeserializer {        // ...}}

Additionally, Spring Boot also now provides JsonObjectSerializer and JsonObjectDeserializerbase classes which provide useful alternatives to the standard Jackson versions when serializing objects. See the updated documentation for details.

Convention based error pages

Custom error pages for a given status code can now be created by following a convention based approach. Create a static HTML file in /public/error or add a template to /templates/error using the status code as the filename. For example, to register a custom 404 file you could addsrc/main/resource/public/error/404.html. See the updated reference documentation for details.

Unified @EntityScan annotation

org.springframework.boot.autoconfigure.domain.EntityScan can now be used to specify the packages to use for JPA, Neo4J, MongoDB, Cassandra and Couchbase. As a result, the JPA-specificorg.springframework.boot.orm.jpa.EntityScan is now deprecated.

ErrorPageRegistry

New ErrorPageRegistry and ErrorPageRegistrar interfaces allow error pages to be registered in a consistent way regardless of the use of an embedded servlet container. The ErrorPageFilter class has been updated to that it is now a ErrorPageRegistry and not a fakeConfigurableEmbeddedServletContainer.

PrincipalExtractor

The PrincipalExtractor interface can now be used if you need to extract the OAuth2 Principalusing custom logic.

Test improvements

Spring Boot 1.4 includes a major overhaul of testing support. Test classes and utilities are now provided in dedicated spring-boot-test and spring-boot-test-autoconfigure jars (although most users will continue to pick them up via the spring-boot-starter-test "Starter"). We’ve added AssertJ, JSONassert and JsonPath dependencies to the test starter.

@SpringBootTest

With Spring Boot 1.3 there were multiple ways of writing a Spring Boot test. You could use@SpringApplicationConfiguration, @ContextConfiguration with theSpringApplicationContextLoader, @IntegrationTest or @WebIntegrationTest. With Spring Boot 1.4, a single @SpringBootTest annotation replaces all of those.

Use @SpringBootTest in combination with @RunWith(SpringRunner.class) and set thewebEnvironment attribute depending on the type of test you want to write.

A classic integration test, with a mocked servlet environment:

@RunWith(SpringRunner.class)
@SpringBootTestpublic class MyTest {    // ...}

A web integration test, running a live server listening on a defined port:

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment=WebEnvionment.DEFINED_PORT)public class MyTest {    // ...}

A web integration test, running a live server listening on a random port:

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment=WebEnvionment.RANDOM_PORT)public class MyTest {	@LocalServerPortprivate int actualPort;	// ...}

See the updated reference documentation for details.

Auto-detection of test configuration

Test configuration can now be automatically detected for most tests. If you follow the Spring Boot recommended conventions for structuring your code the @SpringBootApplication class will be loaded when no explicit configuration is defined. If you need to load a different @Configurationclass you can either include it as a nested inner-class in your test, or use the classes attribute of@SpringBootTest.

See Detecting test configuration for details.

Mocking and spying beans

It’s quite common to want to replace a single bean in your ApplicationContext with a mock for testing purposes. With Spring Boot 1.4 this now as easy as annotating a field in your test with@MockBean:

@RunWith(SpringRunner.class)
@SpringBootTestpublic class MyTest {    @MockBeanprivate RemoteService remoteService;    @Autowiredprivate Reverser reverser;    @Testpublic void exampleTest() {        // RemoteService has been injected into the reverser beangiven(this.remoteService.someCall()).willReturn("mock");        String reverse = reverser.reverseSomeCall();assertThat(reverse).isEqualTo("kcom");}}

You can also use @SpyBean if you want to spy on an existing bean rather than using a full mock.

See the mocking section of the reference documentation for more details.

Auto-configured tests

Full application auto-configuration is sometime overkill for tests, you often only want to auto-configure a specific "slice" of your application. Spring Boot 1.4 introduces a number of specialized test annotations that can be used for testing specific parts of your application:

• @JsonTest - For testing JSON marshalling and unmarshalling.

• @WebMvcTest - For testing Spring MVC @Controllers using MockMVC.

• @RestClientTest - For testing RestTemplate calls.

• @DataJpaTest - For testing Spring Data JPA elements

Many of the annotations provide additional auto-configuration that’s specific to testing. For example, if you use @WebMvcTest you can @Autowire a fully configured MockMvc instance.

See the reference documentation for details.

JSON AssertJ assertions

New JacksonTester, GsonTester and BasicJsonTester classes can be used in combination with AssertJ to test JSON marshalling and unmarshalling. Testers can be used with the @JsonTestannotation or directly on a test class:

@RunWith(SpringRunner.class)
@JsonTestpublic class MyJsonTests {    private JacksonTester json;    @Testpublic void testSerialize() throws Exception {        VehicleDetails details = new VehicleDetails("Honda", "Civic");assertThat(this.json.write(details)).isEqualToJson("expected.json");assertThat(this.json.write(details)).hasJsonPathStringValue("@.make");}}

See the JSON section of the reference documentation or the Javadocs for details.

@RestClientTest

The @RestClientTest annotation can be used if you want to test REST clients. By default it will auto-configure Jackson and GSON support, configure a RestTemplateBuilder and add support forMockRestServiceServer.

Auto-configuration for Spring REST Docs

Combined with the support for auto-configuring MockMvc described above, auto-configuration for Spring REST Docs has been introduced. REST Docs can be enabled using the new@AutoConfigureRestDocs annotation. This will result in the MockMvc instance being automatically configured to use REST Docs and also removes the need to use REST Docs' JUnit rule. Please see the relevant section of the reference documentation for further details.

Test utilities

spring-boot-starter-test now brings the AssertJ assertions library.

Test utilities from the org.springframework.boot.test package have been moved to a spring-boot-test dedicated artifact.

Actuator info endpoint improvements

You can now use the InfoContributor interface to register beans that expose information to the/info actuator endpoint. Out of the box support is provided for:

• Full or partial Git information generated from the git-commit-id-plugin Maven or gradle-git-properties Gradle plugin (set management.info.git.mode=full to expose full details)

• Build information generated from the Spring Boot Maven or Gradle plugin.

• Custom information from the Environment (any property starting info.*)

Details are documented in the "Application information" section of the reference docs.

MetricsFilter improvements

The MetricsFilter can now submit metrics in both the classic "merged" form, or grouped per HTTP method. Use endpoints.metrics.filter properties to change the configuration:

endpoints.metrics.filter.gauge-submissions=grouped
endpoints.metrics.filter.counter-submissions=grouped,merged

Spring Session JDBC Initializer

If Spring Session is configured to use the JDBC store, the schema is now created automatically on startup.

Secured connection for Artemis/HornetQ

Spring Boot now allows to connect against a secured Artemis/HornetQ broker.

Miscellaneous

• server.jetty.acceptors and server.jetty.selectors properties have been added to configure the number of Jetty acceptors and selectors.

• server.max-http-header-size and server.max-http-post-size can be used to constrain maximum sizes for HTTP headers and HTTP POSTs. Settings work on Tomcat, Jetty and Undertow.

• The minimum number of spare threads for Tomcat can now be configured usingserver.tomcat.min-spare-threads

• Profile negation in now supported in application.yml files. Use the familiar ! prefix inspring.profiles values

• The actuator exposes a new headdump endpoint that returns a GZip compressed hprof heap dump file

• Spring Mobile is now auto-configured for all supported template engines

• The Spring Boot maven plugin allows to bundle system scoped artifacts using the newincludeSystemScope attribute

• spring.mvc.log-resolved-exception enables the automatic logging of a warning when an exception is resolved by a HandlerExceptionResolver

• spring.data.cassandra.schema-action you be used to customize the schema action to take on startup

• Spring Boot’s fat jar format should now consume much less memory

• Locale to Charset mapping is now supported via the spring.http.encoding.mapping. property

Spring Data "Ingalls" release train support

Spring Boot 1.4 GA ships with the Spring Data "Hopper" release out of the box. Users that would like to try the "Ingalls" release train (available in milestone one at the time of writing) can do so by just setting the spring-data-releasetrain.version property to Ingalls-M1 and declaring the Spring milestone repository.

Depending on what modules of Spring Data you use, you might have to upgrade a couple of transitive dependencies, too:

• Spring Data REST users will have to upgrade to Spring HATEOAS 0.21 (set spring-hateoas.version to 0.21.0.RELEASE)

• Spring Data Redis users using Jedis as driver will have to upgrade to 2.9 (set jedis.version to2.9.0)

Deprecations in Spring Boot 1.4

• Velocity support has been deprecated since support has been deprecated as of Spring Framework 4.3.

• Some constructors in UndertowEmbeddedServletContainer have been deprecated (most uses should be unaffected).

• The locations and merge attributes of the @ConfigurationProperties annotation have been deprecated in favor of directly configuring the Environment.

• The protected SpringApplication.printBanner method should no longer be used to print a custom banner. Use the Banner interface instead.

• The protected InfoEndpoint.getAdditionalInfo method has been deprecated in favor of theInfoContributor interface.

• org.springframework.boot.autoconfigure.test.ImportAutoConfiguration has been moved toorg.springframework.boot.autoconfigure.

• All classes in the org.springframework.boot.test package have been deprecated. See the "upgrading" notes above for details.

• PropertiesConfigurationFactory.setProperties(Properties) is deprecated in favor of usingPropertySources.

• Several classes in the org.springframework.boot.context.embedded package have been deprecated and relocated to org.springframework.boot.web.servlet.

• All classes in the org.springframework.boot.context.web package have been deprecated and relocated.

• The spring-boot-starter-ws "Starter" has been renamed to spring-boot-starter-web-services.

• The spring-boot-starter-redis "Starter" has been renamed to spring-boot-starter-data-redis.

• The spring-boot-starter-hornetq starter and auto-configuration has been deprecated in favour of using spring-boot-starter-artemis

• management.security.role has been deprecated in favour of management.security.roles

• The @org.springframework.boot.orm.jpa.EntityScan annotation has been deprecated in favor of @org.springframework.boot.autoconfigure.domain.EntityScan or explicit configuration.

• TomcatEmbeddedServletContainerFactory.getValves() has been deprecated in favor ofgetContextValves().

• org.springframework.boot.actuate.system.EmbeddedServerPortFileWriter has been deprecated in favor of org.springframework.boot.system.EmbeddedServerPortFileWriter

• org.springframework.boot.actuate.system.ApplicationPidFileWriter has been deprecated in favor of org.springframework.boot.system.ApplicationPidFileWriter

Property Renames

• spring.jackson.serialization-inclusion should be replaced with spring.jackson.default-property-inclusion.

• spring.activemq.pooled should be replaced with spring.activemq.pool.enabled.

• spring.jpa.hibernate.naming-strategy should be replaced withspring.jpa.hibernate.naming.strategy.

• server.tomcat.max-http-header-size should be replaced with server.max-http-header-size.

redis 的优化免不了要配置的项

redis 官方提供的 conf

https://raw.github.com/antirez/redis/2.2/redis.conf

中6中过期策略的具体方式。
redis 中的默认的过期策略是volatile-lru 。设置方式   

config set maxmemory-policy volatile-lru

maxmemory-policy 六种方式

1. volatile-lru：只对设置了过期时间的key进行LRU（默认值） 

2. allkeys-lru ： 删除lru算法的key   

3. volatile-random：随机删除即将过期key   

4. allkeys-random：随机删除   

5. volatile-ttl ： 删除即将过期的   

6. noeviction ： 永不过期，返回错误  

• 1 打开一个终端，su到root账号

• 2 用你喜欢的编辑器（vi/emacs/...）打开/etc/inittab文件

• 3 查找initdefault关键字，将“id:5:initdefault:”修改为“id:3:initdefault:”

如果系统中根本就没有/etc/inittab文件的话，也没关系，直接创建这个文件，并添加新的一行“id:3”。这样的话，你再重启服务器，便会默认进入命令行状态。当然，如果你只想在临时进入命令行状态，那么直接在终端中输入“init 3”就好了。

至此，我们的命令行准备好了，下面就可以开始通过强大的命令来查看“到底服务器里发生了什么”：

[01    - iostat       ]  [02/03 - meminfo/free ]  [04    - mpstat       ]  [05    - netstat      ]  [06    - nmon         ]  [07    - pmap         ]  [08/09 - ps/pstree    ]  [10    - sar          ]  [11    - strace       ]  [12    - tcpdump      ]  [13    - top          ]  [14    - uptime       ]  [15    - vmstat       ]  [16    - wireshark    ]

[01 - iostat]

iostat命令显示的是你的存储系统的细节状态。你通常可以用这个命令去检测你的存储设备是否工作正常，

完全可以在用户抱怨服务器慢之前，通过这个命令发现系统IO方面的问题。

如下可以看到iostat既可以显示CPU使用情况，也可以看到每个磁盘的IO情况。

# iostat 1  Linux 2.6.32-220.4.1.el6.i686 (roclinux) 2012年12月22日 _i686_ (4 CPU)     avg-cpu: %user %nice %system %iowait %steal %idle  0.55 0.00 0.03 0.02 0.00 99.40     Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn  sdb 0.41 2.61 5.76 2558664 5653872  sda 0.24 0.80 4.12 784650 4038344

[02/03 - meminfo/free]

meminfo提供了很详细的内存使用状况。可以直接用cat命令查看：

cat /proc/meminfo

当然meminfo里包含了太多细节，你可以直接使用free命令来查看有关内存的综述。

# free -m  total used free shared buffers cached  Mem: 1513 1429 83 0 343 836  -/+ buffers/cache: 249 1263  Swap: 0 0 0

[04 - mpstat]

mpstat用在多处理器的服务器上，用来显示每一个CPU的状态。

另外，mpstat也会显示所有处理器的平均状况。

你可以设置显示每个服务器的CPU统计信息，或者每个处理的CPU统计信息。

# mpstat -P ALL  Linux 2.6.32-220.4.1.el6.i686 (roclinux) 2012年12月22日 _i686_ (4 CPU)     17时46分35秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle  17时46分35秒 all 0.55 0.00 0.03 0.02 0.00 0.00 0.00 0.00 99.40  17时46分35秒 0 0.84 0.00 0.04 0.03 0.00 0.01 0.00 0.00 99.08  17时46分35秒 1 0.51 0.00 0.03 0.02 0.00 0.00 0.00 0.00 99.44  17时46分35秒 2 0.45 0.00 0.02 0.01 0.00 0.00 0.00 0.00 99.51  17时46分35秒 3 0.40 0.00 0.02 0.01 0.00 0.00 0.00 0.00 99.56     # mpstat -P 0  Linux 2.6.32-220.4.1.el6.i686 (roclinux) 2012年12月22日 _i686_ (4 CPU)     17时46分39秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle  17时46分39秒 0 0.84 0.00 0.04 0.03 0.00 0.01 0.00 0.00 99.08

其中各个域的含义简述如下：

• 1 CPU：处理器编号，如果为all，则此行表示的是所有处理器的统计平均值

• 2 %usr：用户态的CPU利用率

• 3 %nice：具有调度优先级的用户态CPU利用率

• 4 %sys：内核态CPU利用率（此值不包括响应硬件中断和软件中断的时间）

• 5 %iowait：处理IO请求导致CPU处于IDLE状态的时间百分比

• 6 %irq：CPU响应硬件中断的时间比率

• 7 %soft：CPU响应软件中断的时间比率

• 8 %steal：当虚拟机监控器在服务于其他虚拟处理器时，虚拟CPU的被动等待时间比率

• 9 %guest：运行一个虚拟处理器所消耗的CPU时间比率

[05 - netstat]

netstat命令，是Linux系统管理员几乎每天都会用到的命令（它已经逐步在被ss命令取代），他可以显示很多有关网络方面的信息，例如socket使用情况、路由情况、网卡情况、协议情况、网络流量统计等等。

一些常用的netstat选项包括：

• -a : 显示所有socke信息

• -r : 显示路由信息

• -i : 显示网卡借口统计

• -s : 显示网络协议统计

[06 - nmon]

nmon是Nigel’s Monitor的缩写，它是一个很知名的监视Linux系统性能的工具。

nmon可以查看到处理器利用率、内存使用率、运行队列信息、磁盘IO统计、网络IO统计、换页统计等。

你可以通过一个基于curses的类GUI界面来查看到上述信息。

nmon监控工具

[07 - pmap]

pmap命令可以显示进程占用的内存量。

你可以通过pmap找到那个占用内存量最多的进程。

如下就是nignx主进程所占用的内存情况：

# pmap 2395|head -n 10  2395: nginx: master process ./sbin/nginx  00110000 240K r-x-- /lib/libgssapi_krb5.so.2.2  0014c000 4K ----- /lib/libgssapi_krb5.so.2.2  0014d000 4K r---- /lib/libgssapi_krb5.so.2.2  0014e000 4K rw--- /lib/libgssapi_krb5.so.2.2  0014f000 12K r-x-- /lib/libcom_err.so.2.1  00152000 4K r---- /lib/libcom_err.so.2.1  00153000 4K rw--- /lib/libcom_err.so.2.1  00154000 48K r-x-- /lib/libnss_files-2.12.so  00160000 4K r---- /lib/libnss_files-2.12.so  ...  b78e4000 20K rw--- [ anon ]  b78f3000 4K rw-s- /dev/zero (deleted)  b78f4000 4K rw--- [ anon ]  bfeaa000 84K rw--- [ stack ]  total 7280K

[08/09 - ps/pstree]

ps和pstree在Linux系统里是一对好兄弟，它们都是用来列出处于运行状态的进程的列表的。

ps告诉我们每个进程使用的内存量以及所消耗的CPU时间。

pstree则会告诉我们进程间的父子关系，如下便是mysql的一些父子关系信息：

# pstree -p 1829  mysqld_safe(1829)───mysqld(2307)─┬─{mysqld}(2309)                                   ├─{mysqld}(2310)                                   ├─{mysqld}(2311)                                   ├─{mysqld}(2312)                                   ├─{mysqld}(2313)                                   ├─{mysqld}(2314)                                   ├─{mysqld}(2315)                                   ├─{mysqld}(2316)                                   ├─{mysqld}(2317)                                   ├─{mysqld}(2318)                                   ├─{mysqld}(2320)                                   ├─{mysqld}(2321)                                   ├─{mysqld}(2322)                                   ├─{mysqld}(2323)                                   ├─{mysqld}(2325)                                   ├─{mysqld}(2544)                                   ├─{mysqld}(2548)                                   ├─{mysqld}(7912)                                   ├─{mysqld}(7914)                                   ├─{mysqld}(7916)                                   ├─{mysqld}(24689)                                   ├─{mysqld}(27329)                                   └─{mysqld}(27331)

[10 - sar]

sar命令堪称系统监控工具里的瑞士军刀。

sar命令实际上是由三个程序组成的，即sar（用于显示数据）、sa1(用于采集数据)和sa2（用于存储数据）。

sar可以涵盖到CPU利用率信息、内存换页信息、网络IO传输信息、进程创建行为和存储设备行为。

sar和nmon的最大区别在于，sar更适用于长期的系统监控，而nmon则更适用于快速查看信息。

如果希望更详细的学习sar命令，可以阅读《sar访谈》-linux命令五分钟系列之二十九。

[11 - strace]

starce经常被用来作为追查程序问题的工具，但他的功能远非如此。

它可以解析和记录进程的系统调用行为，这使得strace成为了一个非常有用的诊断、调查和纠错工具。

举例来说，你可以适用strace来追查到一个程序在启动之初所需加载的配置文件信息。

当然，strace也有它自身的缺陷，那就是strace会严重拖慢调查对象（某个进程）的性能和运行速度。

顺便推荐一篇非常好的strace的文章：《strace使用详解》

另外，如果你使用MAC，strace的替代品是truss。

[12 - tcpdump]

tcpdump是一个简单的、好用的网络监控工具。它的网络协议分析能力使得它能够看清网络中到底发生了什么，如果你希望更细节的调查的话，可以考虑适用功能更为强大的wireshark工具。

tcpdump的系列教程“在这里”。

[13 - top]

top命令可以显示系统中的进程信息。默认情况下，top会按照CPU使用率从高到低来显示系统中的进程，并且每5秒刷新一次排行榜。

当然，你也可以让top按照PID、进程寿命、CPU耗时、内存消耗等维度对进程进行排序。（我经常使用的是P和M快捷键，分别是按CPU利用率排序、按内存使用量排序）

通过top命令，你可以很快的发现那些失去控制或不符合预期的进程。

[14 - uptime]

通过uptime命令可以查看系统已经运行了多久，可以统计当前处于登陆状态的用户数量，还可以显示当前服务器的负载情况。

# uptime  18:35:17 up 11 days, 9:30, 1 user, load average: 0.00, 0.00, 0.00

[15 - vmstat]

大多数情况下，你可以使用vmstat命令去查看系统的虚拟内存情况，因为Linux通常会通过虚拟内存来获得更好的存储性能。

如果你的程序占用了大量了内存，那么系统会进行内存页换出的动作，以便把程序从内存中移动到系统SWAP空间中，也就是硬盘中。

如果系统的内存页的换入换出动作频度超过一个临界值，那么这种状态被叫做“Thrashing”。当系统处于thrashing状态时，性能会急剧下降。

vmstat命令便可以帮助人们及时发现此类问题，找出那个拖慢系统的元凶。

# vmstat 1  procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----  r b swpd free buff cache si so bi bo in cs us sy id wa st  2 0 0 57484 356864 861332 0 0 0 1 7 3 1 0 99 0 0  0 0 0 57468 356864 861360 0 0 0 0 336 145 6 1 94 0 0  0 0 0 57468 356864 861360 0 0 0 0 43 51 0 0 100 0 0  0 0 0 57468 356864 861360 0 0 0 16 51 62 0 0 100 0 0

[16 - wireshark]

Wireshark的前身叫做Ethereal,我们可以认为wireshark是tcpdump命令的大师兄，因为wireshark会更为专业，也具有更高级的协议分析和统计能力。

Wireshark同时具有GUI界面和shell借口。

如果你是一位资深的网络管理员，那么你一定使用过ethereal。而如果你正在使用wireshark/ethereal，那么我推荐你阅读Chris Sander的一本非常好的书《Practical Packet Analysis》。

GIT 传输协议实现

在 GIT 的三种主流传输协议 HTTP SSH GIT 中，GIT 协议是最少被使用的协议（也就是 URL 以 git:// 开始的协议）。 这是由于 git 协议的权限控制几乎没有，要么全部可读，要么全部可写，要么全部可读写。所以对于代码托管平台来说， git 协议的目的仅仅是为了支持 公开项目的只读访问。

在 git 的各种传输协议中，git 协议无疑是最高效的，HTTP 受限于 HTTP 的特性，传输过程需要构造 HTTP 请求和响应。 如果是 HTTPS 还涉及到加密解密。另外 HTTP 的超时设置，以及包体大小限制都会影响用户体验。

而 SSH 协议的性能问题主要集中在加密解密上。当然相对于用户的信息安全来说，这些代价都是可以接受。

git 协议实际上相当于 SSH 无加密无验证，也就无从谈起权限控制，但实际上代码托管平台内部的一些同步服务，如果使用 git 协议实现，将会得到很大的性能提升。

传输协议规范

git 协议的技术文档可以从 git 源码目录的 Documentation/technical 找到，即 Packfile transfer protocols 创建 TCP 连接后，git 客户端率先发送请求体，请求格式基于 BNF 的描述如下：

git-proto-request = request-command SP pathname NUL [ host-parameter NUL ]
request-command  = "git-upload-pack" / "git-receive-pack" / "git-upload-archive"; case sensitive
pathname       = *( %x01-ff ) ; exclude NUL
host-parameter   = "host=" hostname [ ":" port ]

一个例子如下：

0033git-upload-pack /project.git\0host=myserver.com\0

在 git 的协议中，pkt-line 是非常有意思的设计，行前 4 个字节表示整个行长，长度包括其前 4 字节， 但是有个特例，0000 其代表行长为 0，但其自身长度是 4。

下面是一个关于请求的结构体：

struct GitRequest{    std::string command;    std::string path;    std::string host;
};

git 有自带的 git-daemon 实现，这个服务程序监听 9418 端口，在接收到客户端的请求后，先要判断 command 是 否是被允许的，git 协议中有 fetch 和 push 以及 archive 之类的操作，分别对应的服务器上的命令是 git-upload-pack git-receive-pack git-upload-archive。HTTP 只会支持前两种，SSH 会支持三种，而 代码托管平台的 git 通常支持的 是 git-upload-pack git-upload-archive。

当不允许的命令被接入时需要发送错误信息给客户端，这个信息在不同的 git-daemon 实现中也不一样，大体 如下所示。

001bERR service not enabled

git-daemon 将对请求路径进行转换，以期得到在服务器上的绝对路径，同时可以判断路径是否存在，不存在时 可以给客户端发送 Repository Not Found。而 host 可能时域名也可能时 ip 地址，当然也可以包括端口。 服务器可以在这里做进一步的限制，出于安全考虑应当考虑到请求是可以被伪造的。

客户端发送请求过去后，服务器将启动相应的命令，将命令标准错误和标准输出的内容发送给客户端，将客户端 传输过来的数据写入到命令的标准输入中来。

在请求体中，命令为 git-upload-pack /project.git 在服务器上运行时，就会类似

git-upload-pack ${RepositoriesRoot}/project.git

出于限制连接的目的，一般还会添加 --timeout=60 这样的参数。timeout 并不是整个操作过程的超时。

与 HTTP 不同的是，git 协议的命令中没有参数 --stateless-rpc 和 --advertise-refs ，在 HTTP 中，两个参数都存在时， 只输出存储库的引用列表与 capabilities，与之对于的是 GET /repository.git/info/refs?service=git-upload(receive)-pack ， 当只有 --stateless-rpc 时，等待客户端的数据，然后解析发送数据给客户端,，与之对应的是 POST /repository.git/git-upload(receive)-pack。

进程输入输出的读写

在 C 语言中，有 popen 函数，可以创建一个进程,并将进程的标准输出或标准输入创建成一个文件指针，即FILE* 其他可以使用 C 函数的语言很多也提供了类似的实现，比如 Ruby，基于 Ruby 的 git HTTP 服务器 grack 正是使用 的 popen，相比与其他语言改造的 popen，C 语言中 popen 存在了一些缺陷，比如无法同时读写，如果要输出标准 错误，需要在命令参数中额外的将标准错误重定向到标准输出。

在 musl libc 的中，popen 的实现如下：

FILE *popen(const char *cmd, const char *mode)
{int p[2], op, e;pid_t pid;FILE *f;posix_spawn_file_actions_t fa;if (*mode == 'r') {op = 0;} else if (*mode == 'w') {op = 1;} else {errno = EINVAL;return 0;}if (pipe2(p, O_CLOEXEC)) return NULL;f = fdopen(p[op], mode);if (!f) {__syscall(SYS_close, p[0]);__syscall(SYS_close, p[1]);return NULL;}FLOCK(f);/* If the child's end of the pipe happens to already be on the final* fd number to which it will be assigned (either 0 or 1), it must* be moved to a different fd. Otherwise, there is no safe way to* remove the close-on-exec flag in the child without also creating* a file descriptor leak race condition in the parent. */if (p[1-op] == 1-op) {int tmp = fcntl(1-op, F_DUPFD_CLOEXEC, 0);if (tmp < 0) {e = errno;goto fail;}__syscall(SYS_close, p[1-op]);p[1-op] = tmp;}e = ENOMEM;if (!posix_spawn_file_actions_init(&fa)) {if (!posix_spawn_file_actions_adddup2(&fa, p[1-op], 1-op)) {if (!(e = posix_spawn(&pid, "/bin/sh", &fa, 0,(char *[]){ "sh", "-c", (char *)cmd, 0 }, __environ))) {posix_spawn_file_actions_destroy(&fa);f->pipe_pid = pid;if (!strchr(mode, 'e'))fcntl(p[op], F_SETFD, 0);__syscall(SYS_close, p[1-op]);FUNLOCK(f);return f;}}posix_spawn_file_actions_destroy(&fa);}
fail:fclose(f);__syscall(SYS_close, p[1-op]);errno = e;return 0;
}

在 Windows Visual C++ 中，popen 源码在 C:\Program Files (x86)\Windows Kits\10\Source\${SDKVersion}\ucrt\conio\popen.cpp ， 按照 MSDN 文档说明，Windows 32 GUI 程序，即 subsystem 是 Windows 的程序，使用 popen 可能导致程序无限失去响应。

所以在笔者实现 git-daemon 及其他 git 服务器时，都不会使用 popen 这个函数。

为了支持跨平台和简化编程，笔者在实现 svn 代理服务器时就使用了 Boost Asio 库，后来也用 Asio 实现过一个 git 远程命令服务， 每一个客户端与服务器连接后，服务器启动程序，需要创建 3 条管道，分别是 子进程的标准输入 输出 错误，即 stdout stdin stderr， 然后注册读写异步事件，将子进程的输出与错误写入到 socket 发送出去，读取 socket 写入到子进程的标准输入中。

在 POSIX 系统中，boost 有一个文件描述符类 boost::asio::posix::stream_descriptor 这个类不能是常规文件，以前用 go 做 HTTP 前端 没注意就 coredump 掉。

在 Windows 系统中，boost 有文件句柄类 boost::asio::windows::stream_handle 此处的文件应当支持随机读取，比如命名管道（当然 在 Windows 系统的，匿名管道实际上也是命名管道的一种特例实现）。

以上两种类都支持 async_read async_write ，所以可以很方便的实现异步的读取。

上面的做法，唯一的缺陷是性能并不是非常高，代码逻辑也比较复杂，当然好处是，错误异常可控一些。

在 Linux 网络通信中，类似与 git 协议这样读取子进程输入输出的服务程序的传统做法是，将 子进程的 IO 重定向到 socket， 值得注意的是 boost 中 socket 是异步非阻塞的，然而，git 命令的标准输入标准错误标准输出都是同步的，所以在 fork 子进程之 前，需要将 socket 设置为同步阻塞，当 fork 失败时，要设置回来。

socket_.native_non_blocking(false);

另外，为了记录子进程是否异常退出，需要注册信号 SIGCHLD 并且使用 waitpid 函数去等待，boost 就有boost::asio::signal_set::async_wait 当然，如果你开发这样一个服务，会发现，频繁的启动子进程，响应信号，管理连接，这些操作才是性能的短板。

一般而言，Windows 平台的 IO 并不能重定向到 socket，实际上，你如果使用 IOCP 也可以达到相应的效率。还有，Windows 的 socket API WSASocket WSADuplicateSocket 复制句柄 DuplicateHandle ，这些可以好好利用。

其他

对于非代码托管平台的从业者来说，上面的相关内容可能显得无足轻重，不过，网络编程都是殊途同归，最后核心理念都是类似的。关于 git-daemon 如果笔者有时间会实现一个跨平台的简易版并开源。

 Zabbix3.0入门到生产环境应用实战视频教程：

http://www.roncoo.com/course/view/fb3050a5b34b42f39ccad83ebebc89c1

龙果运维平台开源项目地址：

https://github.com/roncoo/roncoo-cmdb

最近看了刘天斯老师的机柜展示平台，非常绚丽，而且有大屏显示的话也是能够体现运维价值的，这里就说下我最近在做的CMDB平台的一些数据：

CMDB数据：

 机房，机柜，机柜电源，机柜位置，机房合同，合同到期时间，机房联系人。

 服务器，CPU,硬盘，是否虚拟化，宿主机，raid类型，内存。

 资产ID，上架日期，下架记录，服务器代理商，代理商联系方式，服务器到保日期。

 IP地址，MAC地址，业务线，产品线，操作系统。

通信这块主要技术json-rpc,然后提供Api接口给程序调用，按照固定格式导入即可；硬件固定信息,如IP，MAC，硬盘等信息，通过自动采集的API POST方式加入到数据表。像机房信息，机柜之类的可以给机房抄送一份excel表格然后直接导入即可。

  机房服务器展示：通过把刘天斯老师机柜暂时平台的前端拿过来，然后结合到表结构里面展示；在故障告警的时候，留有一个告警接口的API，通过zabbix 把告警数据发送到运维平台；运维平台入库告警展示:下面是前端简单展示效果，具体操作如下：

前端机柜生成效果显示:闪烁效果直接获取厂商的gif文件调用即可，机柜命名方式比如下面的:5-6,5-7就分别表示第五排第六，第七个机柜：

上面是正常显示，当出现故障时候：就结合zabbix 告警脚本，发送过去给接口，故障如下：

鼠标移动到机柜就显示服务器的相关信息：

zabbix 的告警脚本并且发送状态到运维平台，并且更改服务器状态：

[root@controller alertscripts]# cat zabbix_alert.py 

#!/usr/bin/python

#coding:utf-8 

import requests,json 

import smtplib

from email.mime.text import MIMEText

import sys 

#邮箱服务器地址

mail_host = 'smtp.163.com'

#邮箱用户名

mail_user = 'xxxxx@163.com'

#邮箱密码

mail_pass = 'xxxxxx123456'

mail_postfix = '163.com'

def send_mail(to_list,subject,content):

    me = mail_user+"

    msg = MIMEText(content)

    msg['Subject'] = subject

    msg['From'] = me

    msg['to'] = to_list 

    try:

        s = smtplib.SMTP()

        s.connect(mail_host)

        s.login(mail_user,mail_pass)

        s.sendmail(me,to_list,msg.as_string())

        s.close()

        return True

    except Exception,e:

        print str(e)

        return False

def alert(message):

    headers = {"Content-Type": "application/json"}

    data = {}

    res = {}

    data['status'] = message 

    res['params']=data

    res['jsonrpc'] = "2.0"

    res["id"] = 1

    res["method"]= "alert.turn"

    url = "http://192.168.63.216:2000/api"

    r = requests.post(url, headers=headers,json=res)

if __name__ == "__main__":

    send_mail(sys.argv[1], sys.argv[2], sys.argv[3])

    alert(sys.argv[2])

后端返回状态改变之后直接入库修改，我这边只是判断是否主题是PROBLEM或者OK：

前端代码可以按照刘天斯老师的然后自己修改成jquery即可，前端可以去自由发挥，如下简单样例：

<table border="0" cellpadding="1" cellspacing="0" height="440" width="99%">    

<tbody><tr>    

<td class="jgtable" align="center" height="30" valign="bottom"><font class="jgtitle">01</font></td></tr>      

<td class="jgtable" align="center" height="30" valign="bottom">&nbsp;    

</td>    

</tr>    

<tr>    

<td class="jgtable" align="center" height="30" valign="bottom">&nbsp;    

</td>    

</tr>    

<tr>    

<td class="jgtable" align="center" height="30" valign="bottom">&nbsp;    

</td>    

</tr>    

<tr>    

<td class="jgtable" align="center" height="30" valign="bottom">&nbsp;    

</td>    

</tr>    

<tr>    

<td class="jgtable" align="center" height="30" valign="bottom">&nbsp;    

</td>    

</tr>    

</tbody></table>

方法一：多个.conf方法（优点是灵活，缺点就是站点比较多配置起来麻烦）

这里以配置2个站点（2个域名）为例，n 个站点可以相应增加调整，假设：

IP地址: 202.55.1.100
域名1 example1.com 放在 /www/example1
域名2 example2.com 放在 /www/example2

配置 nginx virtual hosting 的基本思路和步骤如下：

把2个站点 example1.com, example2.com 放到 nginx 可以访问的目录 /www/
给每个站点分别创建一个 nginx 配置文件 example1.com.conf，example2.com.conf, 并把配置文件放到 /etc/nginx/vhosts/
然后在 /etc/nginx.conf 里面加一句 include 把步骤2创建的配置文件全部包含进来（用 * 号）
重启 nginx

具体过程

下面是具体的配置过程：

1、在 /etc/nginx 下创建 vhosts 目录

mkdir /etc/nginx/vhosts

2、在 /etc/nginx/vhosts/ 里创建一个名字为 example1.com.conf 的文件，把以下内容拷进去

server {listen  80;server_name  example1.com www. example1.com;access_log  /www/access_ example1.log  main;location / {root   /www/example1.com;index  index.php index.html index.htm;}error_page   500 502 503 504  /50x.html;location = /50x.html {root   /usr/share/nginx/html;}# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000location ~ .php$ {fastcgi_pass   127.0.0.1:9000;fastcgi_index  index.php;fastcgi_param  SCRIPT_FILENAME  /www/example1.com/$fastcgi_script_name;include        fastcgi_params;}location ~ /.ht {deny  all;}
}

3、在 /etc/nginx/vhosts/ 里创建一个名字为 example2.com.conf 的文件，把以下内容拷进去

server {listen  80;server_name  example2.com www. example2.com;access_log  /www/access_ example1.log  main;location / {root   /www/example2.com;index  index.php index.html index.htm;}error_page   500 502 503 504  /50x.html;location = /50x.html {root   /usr/share/nginx/html;}# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000location ~ .php$ {fastcgi_pass   127.0.0.1:9000;fastcgi_index  index.php;fastcgi_param  SCRIPT_FILENAME  /www/example2.com/$fastcgi_script_name;include        fastcgi_params;}location ~ /.ht {deny  all;}
}

4、打开 /etc/nginix.conf 文件，在相应位置加入 include 把以上2个文件包含进来

user  nginx;
worker_processes  1;# main server error log
error_log	/var/log/nginx/error.log ;
pid	/var/run/nginx.pid;events {worker_connections  1024;
}# main server config
http {include       mime.types;default_type  application/octet-stream;log_format  main  '$remote_addr - $remote_user [$time_local] $request ''"$status" $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';sendfile        on;#tcp_nopush     on;#keepalive_timeout  0;keepalive_timeout  65;gzip  on;server {listen         80;server_name     _;access_log      /var/log/nginx/access.log main;server_name_in_redirect  off;location / {root  /usr/share/nginx/html;index index.html;}}# 包含所有的虚拟主机的配置文件include /usr/local/etc/nginx/vhosts/*;
}

5、重启 Nginx

/etc/init.d/nginx restart方法二：动态目录方法（优点是方便，每个域名对应一个文件夹，缺点是不灵活）

这个简单的方法比起为每一个域名建立一个 vhost.conf 配置文件来讲，只需要在现有的配置文件中增加如下内容：

# Replace this port with the right one for your requirements
# 根据你的需求改变此端口
listen       80;  #could also be 1.2.3.4:80 也可以是1.2.3.4:80的形式
# Multiple hostnames seperated by spaces.  Replace these as well.
# 多个主机名可以用空格隔开，当然这个信息也是需要按照你的需求而改变的。
server_name  star.yourdomain.com *.yourdomain.com http://www.*.yourdomain.com/;
#Alternately: _ *
#或者可以使用：_ * (具体内容参见本维基其他页面)
root /PATH/TO/WEBROOT/$host;
error_page  404              http://yourdomain.com/errors/404.html;
access_log  logs/star.yourdomain.com.access.log;
location / {
root   /PATH/TO/WEBROOT/$host/;
index  index.php;
}
# serve static files directly
# 直接支持静态文件 (从配置上看来不是直接支持啊)
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html)$ {
access_log        off;
expires           30d;
}
location ~ .php$ {
# By all means use a different server for the fcgi processes if you need to
# 如果需要，你可以为不同的FCGI进程设置不同的服务信息
fastcgi_pass   127.0.0.1:YOURFCGIPORTHERE;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  /PATH/TO/WEBROOT/$host/$fastcgi_script_name;
fastcgi_param  QUERY_STRING     $query_string;
fastcgi_param  REQUEST_METHOD   $request_method;
fastcgi_param  CONTENT_TYPE     $content_type;
fastcgi_param  CONTENT_LENGTH   $content_length;
fastcgi_intercept_errors on;
}
location ~ /.ht {
deny  all;
}

最后附另外一个二级域名匹配的方法

绑定域名
server_name *.abcd.com;
获取主机名
if ( $host ~* (.*).(.*).(.*))
{
set $domain $1;
}
定义目录
root html/abc/$domain/;
location /
{
root html/abcd/$domain;
index index.html index.php;

前言

目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。

基础理论相关

说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。

ACID 特性

A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行；

C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确；

I（隔离性）保证事务不受外部并发操作的独立环境执行；

D（持久性）事务完成之后，对于数据的修改是永久的，即使系统出现故障也能够保持；

CAP

C（一致性）一致性是指数据的原子性，在经典的数据库中通过事务来保障，事务完成时，无论成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致；

A（可用性）服务一直保持可用的状态，当用户发出一个请求，服务能在一定的时间内返回结果；

P（分区容忍性）在分布式应用中，可能因为一些分布式的原因导致系统无法运转，好的分区容忍性，使应用虽然是一个分布式系统，但是好像一个可以正常运转的整体

BASE

BA: Basic Availability 基本业务可用性；

S: Soft state 柔性状态；

E: Eventual consistency 最终一致性；

最终一致性的几种做法

单数据库情况下的事务

如果应用系统是单一的数据库，那么这个很好保证，利用数据库的事务特性来满足事务的一致性，这时候的一致性是强一致性的。对于java应用系统来讲，很少直接通过事务的start和commit以及rollback来硬编码，大多通过spring的事务模板或者声明式事务来保证。

基于事务型消息队列的最终一致性

借助消息队列，在处理业务逻辑的地方，发送消息，业务逻辑处理成功后，提交消息，确保消息是发送成功的，之后消息队列投递来进行处理，如果成功，则结束，如果没有成功，则重试，直到成功，不过仅仅适用业务逻辑中，第一阶段成功，第二阶段必须成功的场景。对应上图中的C流程。

基于消息队列+定时补偿机制的最终一致性

前面部分和上面基于事务型消息的队列，不同的是，第二阶段重试的地方，不再是消息中间件自身的重试逻辑了，而是单独的补偿任务机制。其实在大多数的逻辑中，第二阶段失败的概率比较小，所以单独独立补偿任务表出来，可以更加清晰，能够比较明确的直到当前多少任务是失败的。对应上图的E流程。

业务系统业务逻辑的commit/rollback机制

这一点说的话确实不难，commit和rollback是数据库事务中的比较典型的概念，但是在系统分布式情况下，需要业务代码中实现这种，成功了commit，失败了rollback。

业务应用系统的幂等性控制

为啥要做幂等呢？ 原因很简单，在系统调用没有达到期望的结果后，会重试。那重试就会面临问题，重试之后不能给业务逻辑带来影响，例如创建订单，第一次调用超时了，但是调用的系统不知道超时了是成功了还是失败了，然后他就重试，但是实际上第一次调用订单创建是成功了的，这时候重试了，显然不能再创建订单了。

--查询

查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何数据的变更，所以，查询一次和查询多次一样的。

--MVCC方案

多版本并发控制，update with condition，更新带条件，这也是在系统设计的时候，合理的选择乐观锁，通过version或者其他条件，来做乐观锁，这样保证更新及时在并发的情况下，也不会有太大的问题。例如update tablexxx set name=#name#,version=version+1 where version=#version# ,或者是 update tablexxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。

--单独的去重表

如果涉及到的去重的地方特别多，例如ERP系统中有各种各样的业务单据，每一种业务单据都需要去重，这时候，可以单独搞一张去重表，在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

--分布式锁

还是拿插入数据的例子，如果是分布是系统，构建唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。

--删除数据

删除数据，仅仅第一次删除是真正的操作数据，第二次甚至第三次删除，直接返回成功，这样保证了幂等。

--插入数据的唯一索引

插入数据的唯一性，可以通过业务主键来进行约束，例如一个特定的业务场景，三个字段肯定确定唯一性，那么，可以在数据库表添加唯一索引来进行标示。

--API层面的幂等

这里有一个场景，API层面的幂等，例如提交数据，如何控制重复提交，这里可以在提交数据的form表单或者客户端软件，增加一个唯一标示，然后服务端，根据这个UUID来进行去重，这样就能比较好的做到API层面的唯一标示。

--状态机幂等

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

异步回调机制的引入

A应用调用B，在同步调用的返回结果中，B返回成功给到A，一般情况下，这时候就结束了，其实在99.99%的情况是没问题的，但是有时候为了确保100%，记住最起码在系统设计中100%，这时候B系统再回调A一下，告诉A，你调用我的逻辑，确实成功了。其实这个逻辑，非常类似TCP协议中的三次握手。上图中的B流程。

类似double check机制的确认机制

还是上图中异步回调的过程，A在同步调用B，B返回成功了。这次调用结束了，但是A为了确保，在过一段时间，这个时间可以是几秒，也可以是每天定时处理，再调用B一次，查询一下之前的那次调用是否成功。例如A调用B更新订单状态，这时候成功了，延迟几秒后，A查询B，确认一下状态是否是自己刚刚期望的。上图中的D流程。

总结

上面的几点总结，更多的在业务系统中体现，在超复杂的系统中，数据的一致性，不是说简单的引入啥中间件能够解决的，更多的是根据业务场景，来灵活应对。

1、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、分布式事务的产生的原因

2.1、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

2.2、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！

3、事务的ACID特性

3.1、原子性（A）

所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

3.2、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

3.3、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

3.4、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

4、分布式事务的应用场景

4.1、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

4.2、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

5、常见的分布式事务解决方案

5.1、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

5.2、消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

1、A系统向消息中间件发送一条预备消息
2、消息中间件保存预备消息并返回成功
3、A执行本地事务
4、A发送提交消息给消息中间件

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

• 步骤一出错，则整个事务失败，不会执行A的本地操作

• 步骤二出错，则整个事务失败，不会执行A的本地操作

• 步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息

• 步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

5.3、TCC编程模式

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力！

摘要：本文来自Nginx官方博客，是微服务系列文章的第一篇，主要探讨了传统的单体式应用的不足，以及微服务架构的优势与挑战。正如作者所说，微服务架构更适合用于构建复杂的应用，尽管它也有自己的不足。

这篇文章作者是Chris Richardson，他是早期基于Java的Amazonite EC2 PaaS平台CloudFoundry.com的创始人。现在他为企业提供如何开发和部署应用的咨询服务。他也经常在http://microservices.io上发表有关微服务的文章。

微服务正在博客、社交媒体讨论组和会议演讲中获得越来越多的关注，在Gartner的2014 Hype Cycle上它的排名非常靠前。同时，软件社区中也有不少持怀疑论者，认为微服务不是什么新东西。Naysayers认为这就是SOA架构的重新包装。然而，尽管存在着不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。

　　这篇博客是关于如何设计、开发和部署微服务的七篇系列文章中的第一篇。读者将会从中学到方法，并且和单体式架构模式（译者注：本文中会将 Monolithic翻译为单体）进行对比。这一系列文章将描述微服务架构中不同元素。你将了解到微服务架构模式的优缺点，以便决定是否更好的将微服务架构应用到自己的项目中，以及如何应用这一模式。

　　首先我们看看为什么要考虑使用微服务。

　　开发单体式应用

　　假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图如下：

　应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

　　尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，同样，Rails和Node.js会被打包成层级目录。

　　这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用Selenium链接UI就可以完成端到端测试。单体式应用也易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。

　　单体式应用的不足

　　不幸的是，这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中，开发团队都会面对新“故事”，然后开发许多新代码。几年后，这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子，我最近和一个开发者讨论，他正在写一个工具，用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是很多开发者经过多年努力开发出来的一个怪物。

　　一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。

　　单体式应用也会降低开发速度。应用越大，启动时间会越长。比如，最近的一个调查表明，有时候应用的启动时间居然超过了12分钟。我还听说某些应用需要40分钟启动时间。如果开发者需要经常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。

　　另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。另外，这种变化带来的影响并没有很好的被理解，所以不得不做很多手工测试。那么接下来，持续部署也会很艰难。

　　单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另外一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。

　　单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。

　　最后，单体式应用使得采用新架构和语言非常困难。比如，设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架，无论是时间还是成本都是非常昂贵的，即使ABC框架更好。因此，这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。

　　总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。

　　那么如何应对呢？

　　微处理架构——处理复杂事物

　　许多公司，比如Amazon、eBay和NetFlix，通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。

　　一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。

　　比如，一个前面描述系统可能的分解如下：

每一个应用功能区都使用微服务完成，另外，Web应用会被拆分成一系列简单的Web应用（比如一个对乘客，一个对出租车驾驶员）。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。

　　每一个后台服务开放一个REST API，许多服务本身也采用了其它服务提供的API。比如，驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的，基于消息的通讯。微服务内部机制将会在后续系列中讨论。

　　一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务，而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，可以通过NGINX方便实现，后续文章将会介绍到API Gateway。

·微服务架构模式在上图中对应于代表可扩展Scale Cube的Y轴，这是一个在《The Art of Scalability》书中描述过的三维扩展模型。另外两个可扩展轴，X轴由负载均衡器后端运行的多个应用副本组成，Z轴是将需求路由到相关服务。

　　应用基本可以用以上三个维度来表示，Y轴代表将应用分解为微服务。运行时，X轴代表运行多个隐藏在负载均衡器之后的实例，提供吞吐能力。一些应用可能还是用Z轴将服务分区。下面的图演示行程管理服务如何部署在运行于AWS EC2上的Docker上。

运行时，行程管理服务由多个服务实例构成。每一个服务实例都是一个Docker容器。为了保证高可用，这些容器一般都运行在多个云VM上。服务实例前是一层诸如NGINX的负载均衡器，他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求，例如缓存、权限控制、API统计和监控。

　　这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。

每种服务都有自己的数据库，另外，每种服务可以用更适合自己的数据库类型，也被称作多语言一致性架构。比如，驾驶员管理（发现哪个驾驶员更靠近乘客），必须使用支持地理信息查询的数据库。

　　表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。但是，可以从另外一个角度看此问题，微服务架构模式是一个不包含Web服务（WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。

　　微服务架构的好处

　　微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。

　　第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。

　　第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

　　最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。

　　微服务架构的不足

　　Fred Brooks在30年前写道，“there are no silver bullets”，像任何其它科技一样，微服务架构也有不足。其中一个跟他的名字类似，『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。

　　另外一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。

　　另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

　　测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。

　　另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

　　部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成。例如，根据Adrian Cockcroft，Hailo有160个不同服务构成，NetFlix有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制（后续文章中发表），以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。

　　一种自动化方法是使用PaaS服务，例如Cloud Foundry。PaaS给开发者提供一个部署和管理微服务的简单方法，它把所有这些问题都打包内置解决了。同时，配置PaaS的系统和网络专家可以采用最佳实践和策略来简化这些问题。另外一个自动部署微服务应用的方法是开发对于你来说最基础的PaaS系统。一个典型的开始点是使用一个集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我们会看看如何基于软件部署方法例如NGINX，可以方便的在微服务层面提供缓存、权限控制、API统计和监控。

　　总结

　　构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。