texec);\n\n}\n```\n\n这里需要解释一下，上述实际分成了两大类:\n* exec 无返回值的rpc调用\n* call 有返回值的调用\n\n这里使用了Java 8的函数式编程进行抽象。如果不太熟悉的朋友，可以自行查阅相关资料。\n\n在函数式编程的帮助下，我们可以将每一个rpc调用都分为同步和异步两种，异步的调用会返回一个Future。\n\n再来看一下AbstractThriftClient:\n```java\n/**\n * @(#)AbstractThriftClient.java, Aug 01, 2017.\n * \n * Copyright 2017 fenbi.com. All rights reserved.\n * FENBI.COM PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.\n */\npackage com.coder4.lmsia.thrift.client;\n\nimport com.coder4.lmsia.thrift.client.func.ThriftCallFunc;\nimport com.coder4.lmsia.thrift.client.func.ThriftExecFunc;\nimport org.apache.thrift.TServiceClient;\nimport org.apache.thrift.TServiceClientFactory;\nimport org.apache.thrift.protocol.TBinaryProtocol;\nimport org.apache.thrift.protocol.TProtocol;\nimport org.apache.thrift.transport.TTransport;\n\nimport java.util.concurrent.ExecutorService;\nimport java.util.concurrent.Future;\nimport java.util.concurrent.LinkedBlockingDeque;\nimport java.util.concurrent.ThreadPoolExecutor;\nimport java.util.concurrent.TimeUnit;\n\n/**\n * @author coder4\n */\npublic abstract class AbstractThriftClient implements ThriftClient {\n\n protected static final int THRIFT_CLIENT_DEFAULT_TIMEOUT = 5000;\n\n protected static final int THRIFT_CLIENT_DEFAULT_MAX_FRAME_SIZE = 1024 * 1024 * 16;\n\n private Class thriftClass;\n\n private static final TBinaryProtocol.Factory protocolFactory = new TBinaryProtocol.Factory();\n\n private TServiceClientFactory clientFactory;\n\n // For async call\n private ExecutorService threadPool;\n\n public void init() {\n try {\n clientFactory = getThriftClientFactoryClass().newInstance();\n } catch (Exception e) {\n throw new RuntimeException();\n }\n\n if (!check()) {\n throw new RuntimeException(\"Client config failed check!\");\n }\n\n threadPool = new ThreadPoolExecutor(\n 10, 100, 0,\n TimeUnit.MICROSECONDS, new LinkedBlockingDeque<>());\n }\n\n protected boolean check() {\n if (thriftClass == null) {\n return false;\n }\n return true;\n }\n\n @Override\n public Future asyncCall(ThriftCallFunc tcall) {\n return threadPool.submit(() -> this.call(tcall));\n }\n\n @Override\n public Future asyncExec(ThriftExecFunc texec) {\n return threadPool.submit(() -> this.exec(texec));\n }\n\n protected TCLIENT createClient(TTransport transport) throws Exception {\n // Step 1: get TProtocol\n TProtocol protocol = protocolFactory.getProtocol(transport);\n\n // Step 2: get client\n return clientFactory.getClient(protocol);\n }\n\n private Class> getThriftClientFactoryClass() {\n Class clientClazz = getThriftClientClass();\n if (clientClazz == null) {\n return null;\n }\n for (Class clazz : clientClazz.getDeclaredClasses()) {\n if (TServiceClientFactory.class.isAssignableFrom(clazz)) {\n return (Class>) clazz;\n }\n }\n return null;\n }\n\n private Class getThriftClientClass() {\n for (Class clazz : thriftClass.getDeclaredClasses()) {\n if (TServiceClient.class.isAssignableFrom(clazz)) {\n return (Class) clazz;\n }\n }\n return null;\n }\n\n public void setThriftClass(Class thriftClass) {\n this.thriftClass = thriftClass;\n }\n}\n```\n\n上述抽象的Thrift客户端实现了如下功能：\n1. 客户端线程池，这里主要是为异步调用准备的，与之前构造的服务端的线程池是完全不同的。\n * asyncCall和asyncExec使用了线程池来完成异步调用\n1. thriftClass 存储了Thrift的桩代码了类，不同业务生成的ThriftClass不一样，所以这里存储了class。\n1. createClient提供了共用函数，传入一个transport，即可构造生成一个Thrift Client，特别注意的是，这里设定的通信协议为TBinaryProtocol，必须与服务端保持一致，否则无法成功通信。\n\n由于call和exec与连接实现较为相关，因此并未在这一层中实现，最后我们来看一下EasyThriftClient:\n```java\npackage com.coder4.lmsia.thrift.client;\n\nimport com.coder4.lmsia.thrift.client.func.ThriftCallFunc;\nimport com.coder4.lmsia.thrift.client.func.ThriftExecFunc;\nimport org.apache.thrift.TServiceClient;\nimport org.apache.thrift.transport.TFramedTransport;\nimport org.apache.thrift.transport.TSocket;\nimport org.apache.thrift.transport.TTransport;\n\n/**\n * @author coder4\n */\npublic class EasyThriftClient extends AbstractThriftClient {\n\n private static final int EASY_THRIFT_BUFFER_SIZE = 1024 * 16;\n\n protected String thriftServerHost;\n\n protected int thriftServerPort;\n\n @Override\n protected boolean check() {\n if (thriftServerHost == null || thriftServerHost.isEmpty()) {\n return false;\n }\n if (thriftServerPort <= 0) {\n return false;\n }\n return super.check();\n }\n\n private TTransport borrowTransport() throws Exception {\n TSocket socket = new TSocket(thriftServerHost, thriftServerPort, THRIFT_CLIENT_DEFAULT_TIMEOUT);\n\n TTransport transport = new TFramedTransport(\n socket, THRIFT_CLIENT_DEFAULT_MAX_FRAME_SIZE);\n\n transport.open();\n\n return transport;\n }\n\n private void returnTransport(TTransport transport) {\n if (transport != null && transport.isOpen()) {\n transport.close();\n }\n }\n\n private void returnBrokenTransport(TTransport transport) {\n if (transport != null && transport.isOpen()) {\n transport.close();\n }\n }\n\n @Override\n public TRET call(ThriftCallFunc tcall) {\n\n // Step 1: get TTransport\n TTransport tpt = null;\n try {\n tpt = borrowTransport();\n } catch (Exception e) {\n throw new RuntimeException(e);\n }\n\n // Step 2: get client & call\n try {\n TCLIENT tcli = createClient(tpt);\n TRET ret = tcall.call(tcli);\n returnTransport(tpt);\n return ret;\n } catch (Exception e) {\n returnBrokenTransport(tpt);\n throw new RuntimeException(e);\n }\n }\n\n @Override\n public void exec(ThriftExecFunc texec) {\n // Step 1: get TTransport\n TTransport tpt = null;\n try {\n tpt = borrowTransport();\n } catch (Exception e) {\n throw new RuntimeException(e);\n }\n\n // Step 2: get client & exec\n try {\n TCLIENT tcli = createClient(tpt);\n texec.exec(tcli);\n returnTransport(tpt);\n } catch (Exception e) {\n returnBrokenTransport(tpt);\n throw new RuntimeException(e);\n }\n }\n\n public String getThriftServerHost() {\n return thriftServerHost;\n }\n\n public void setThriftServerHost(String thriftServerHost) {\n this.thriftServerHost = thriftServerHost;\n }\n\n public int getThriftServerPort() {\n return thriftServerPort;\n }\n\n public void setThriftServerPort(int thriftServerPort) {\n this.thriftServerPort = thriftServerPort;\n }\n\n```\n\n简单解释下上述代码\n1. 需要外部传入RPC服务器的主机名和端口 thriftServerHost和thriftServerPort\n1. borrowTransport完成Transport(Thrift中类似Socket的抽象) 的构造，注意这里要使用TFramedTransport，与之前服务端的构造保持一致。\n1. returnTransport关闭Transport\n1. returnBrokenTransport关闭出异常的Transport\n1. call和exec 在拿到Transport后，使用函数式编程的方式，完成rpc调用，如果有异常则关闭连接。\n\n最后我们来看一下对应的Builder，EasyThriftClientBuilder:\n```java\npackage com.coder4.lmsia.thrift.client.builder;\n\nimport com.coder4.lmsia.thrift.client.EasyThriftClient;\nimport org.apache.thrift.TServiceClient;\n\n/**\n * @author coder4\n */\npublic class EasyThriftClientBuilder {\n\n private final EasyThriftClient client = new EasyThriftClient<>();\n\n protected EasyThriftClient build() {\n client.init();\n return client;\n }\n\n protected EasyThriftClientBuilder setHost(String host) {\n client.setThriftServerHost(host);\n return this;\n }\n\n protected EasyThriftClientBuilder setPort(int port) {\n client.setThriftServerPort(port);\n return this;\n }\n\n protected EasyThriftClientBuilder setThriftClass(Class thriftClass) {\n client.setThriftClass(thriftClass);\n return this;\n }\n}\n\n```\n\nBuilder的代码比较简单，就是以链式调用的方式，通过主机和端口，方便地构造一个EasyThriftClient。\n\n看了EasyThriftClient后下面我们来看一下如何集成到项目中。\n\n在[Gradle子项目划分与微服务的代码结构](sb-gradle-structure.md)一节中，我们已经提到，将每个微服务的RPC客户端放在xx-client子工程中，现在我们再来回顾下lmsia-abc-client的目录结构。\n\n```shell\n├── build.gradle\n└── src\n ├── main\n │ ├── java\n │ │ └── com\n │ │ └── coder4\n │ │ └── lmsia\n │ │ └── abc\n │ │ └── client\n │ │ ├── configuration\n │ │ │ └── LmsiaAbcThriftClientConfiguration.java\n │ │ ├── LmsiaAbcEasyThriftClientBuilder.java\n │ │ └── LmsiaK8ServiceThriftClientBuilder.java\n │ └── resources\n │ └── META-INF\n │ └── spring.factories\n └── test\n\n```\n\n我们简单介绍一下：\n1. LmsiaAbcThriftClientConfiguration: 客户端自动配置，当激活时，自动生成lmsia-abc对应的RPC服务的客户端。引用者直接@Autowired一下，就可以使用了。\n1. LmsiaAbcEasyThriftClientBuilder: EasyThriftClient构造器，主要是自动配置需要。\n1. spring.factories: 与服务端的自动配置类似，需要在这个文件中指定自动配置的类路径，才能让Spring Boot自动扫描到自动配置。\n1. 其他K8ServiceThriftClient相关的部分，我们将在下一小节进行介绍。\n\nLmsiaAbcEasyThriftClientBuilder文件：\n\n```java\npackage com.coder4.lmsia.abc.client;\n\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift;\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift.Client;\nimport com.coder4.lmsia.thrift.client.ThriftClient;\nimport com.coder4.lmsia.thrift.client.builder.EasyThriftClientBuilder;\n\n/**\n * @author coder4\n */\npublic class LmsiaAbcEasyThriftClientBuilder extends EasyThriftClientBuilder {\n\n public LmsiaAbcEasyThriftClientBuilder(String host, int port) {\n setThriftClass(LmsiaAbcThrift.class);\n\n setHost(host);\n setPort(port);\n }\n\n public static ThriftClient buildClient(String host, int port) {\n return new LmsiaAbcEasyThriftClientBuilder(host, port).build();\n }\n\n}\n\n```\n\n上述Builder完成了实际的参数填充，主要有：\n1. ThriftClient的桩代码类设置(LmsiaAbcThrift.class)\n1. 设置主机名和端口\n\nLmsiaAbcClientConfiguration文件：\n\n```java\npackage com.coder4.lmsia.abc.client.configuration;\n\nimport com.coder4.lmsia.abc.client.LmsiaAbcEasyThriftClientBuilder;\nimport com.coder4.lmsia.abc.client.LmsiaK8ServiceClientBuilder;\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift;\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift.Client;\nimport com.coder4.lmsia.thrift.client.K8ServiceKey;\nimport com.coder4.lmsia.thrift.client.ThriftClient;\nimport org.slf4j.Logger;\nimport org.slf4j.LoggerFactory;\nimport org.springframework.beans.factory.annotation.Qualifier;\nimport org.springframework.beans.factory.annotation.Value;\nimport org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;\nimport org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;\nimport org.springframework.context.annotation.Bean;\nimport org.springframework.context.annotation.Configuration;\nimport org.springframework.context.annotation.Profile;\n\n@Configuration\npublic class LmsiaAbcThriftClientConfiguration {\n\n private Logger LOG = LoggerFactory.getLogger(getClass());\n\n @Bean(name = \"lmsiaAbcThriftClient\")\n @ConditionalOnMissingBean(name = \"lmsiaAbcThriftClient\")\n @ConditionalOnProperty(name = {\"lmsiaAbcThriftServer.host\", \"lmsiaAbcThriftServer.port\"})\n public ThriftClient easyThriftClient(\n @Value(\"${lmsiaAbcThriftServer.host}\") String host,\n @Value(\"${lmsiaAbcThriftServer.port}\") int port\n ) {\n LOG.info(\"######## LmsiaAbcClientConfiguration ########\");\n LOG.info(\"easyClient host = {}, port = {}\", host, port);\n return LmsiaAbcEasyThriftClientBuilder.buildClient(host, port);\n }\n\n}\n\n```\n\n如上所示，满足两个条件时，会自动构造LmsiaAbcEasyThriftClient：\n1. 还没有生成其他的LmsiaAbcEasyThriftClient(ConditionalOnMissingBean)\n2. 配置中指定了lmsiaAbcThriftServer.host和lmsiaAbcThriftServer.port\n\n根据我们前面的介绍，大家应该能理解，虽然有自动配置，但上述配置是一种很糟糕的方式。试想一下，如果我们的服务依赖了5个其他RPC服务，那么岂不是要分别配置5组IP和端口？此外，这种方式也无法支持节点的负载均衡。\n\n如何解决这个问题呢？我们将在K8ServiceThriftClient中解决。\n\n本小节的最后，我们看一下spring.factories:\n```shell\norg.springframework.boot.autoconfigure.EnableAutoConfiguration=com.coder4.lmsia.abc.client.configuration.LmsiaAbcThriftClientConfiguration\n\n```\n\n和之前lmsia-abc-server子工程中的文件类似，这里设置了自动配置的详细类路径，方便Spring Boot的自动扫描。\n\n## K8ServiceThriftClient \n\n在对EasyThriftClient的介绍中，我们发现了一个问题，需要单独配置IP和端口，不支持服务自动发现。\n\n此外，在这个客户端的实现中，默认每次都要建立新的连接。而对于后端服务而言，RPC的服务端和客户端多数都是在内网环境中，连接情况比较稳定，可以通过连接池的方式减少连接握手开销，从而提升RPC服务的性能。如果你对连接池的原理还不太熟悉，可以参考[百科连接池](https://baike.baidu.com/item/%E8%BF%9E%E6%8E%A5%E6%B1%A0)\n\n为此，我们本将介绍K8ServiceThriftClient，它很好的解决了上述问题。\n\n首先，我们使用commons-pool2来构建了TTransport层的连接池。\n\nTTransportPoolFactory:\n\n```java\npackage com.coder4.lmsia.thrift.client.pool;\n\nimport com.coder4.lmsia.thrift.client.K8ServiceKey;\nimport org.apache.commons.pool2.BaseKeyedPooledObjectFactory;\nimport org.apache.commons.pool2.PooledObject;\nimport org.apache.commons.pool2.impl.DefaultPooledObject;\nimport org.apache.thrift.transport.TFramedTransport;\nimport org.apache.thrift.transport.TSocket;\nimport org.apache.thrift.transport.TTransport;\n\n/**\n * @author coder4\n */\npublic class TTransportPoolFactory extends BaseKeyedPooledObjectFactory {\n\n protected static final int THRIFT_CLIENT_DEFAULT_TIMEOUT = 5000;\n\n protected static final int THRIFT_CLIENT_DEFAULT_MAX_FRAME_SIZE = 1024 * 1024 * 16;\n\n @Override\n public TTransport create(K8ServiceKey key) throws Exception {\n if (key != null) {\n String host = key.getK8ServiceHost();\n int port = key.getK8ServicePort();\n TSocket socket = new TSocket(host, port, THRIFT_CLIENT_DEFAULT_TIMEOUT);\n\n TTransport transport = new TFramedTransport(\n socket, THRIFT_CLIENT_DEFAULT_MAX_FRAME_SIZE);\n\n transport.open();\n\n return transport;\n } else {\n return null;\n }\n }\n\n @Override\n public PooledObject wrap(TTransport transport) {\n return new DefaultPooledObject<>(transport);\n }\n\n @Override\n public void destroyObject(K8ServiceKey key, PooledObject obj) throws Exception {\n obj.getObject().close();\n }\n\n @Override\n public boolean validateObject(K8ServiceKey key, PooledObject obj) {\n return obj.getObject().isOpen();\n }\n\n}\n```\n\n上述代码主要完成以下功能：\n1. 连接超时配置(5秒)\n1. create, 生成新连接（TTransport），这里与之前的EasyThriftClient非常类似，不再赘述\n1. 验证连接是否有效，通过TTransport的isOpen判断。\n\nTTransportPool:\n```java\npackage com.coder4.lmsia.thrift.client.pool;\n\nimport com.coder4.lmsia.thrift.client.K8ServiceKey;\nimport org.apache.commons.pool2.impl.GenericKeyedObjectPool;\nimport org.apache.thrift.transport.TTransport;\nimport org.slf4j.Logger;\nimport org.slf4j.LoggerFactory;\n\n/**\n * @author coder4\n */\npublic class TTransportPool extends GenericKeyedObjectPool {\n\n private Logger LOG = LoggerFactory.getLogger(getClass());\n\n private static int MAX_CONN = 1024;\n private static int MIN_IDLE_CONN = 8;\n private static int MAX_IDLE_CONN = 32;\n\n public TTransportPool(TTransportPoolFactory factory) {\n super(factory);\n\n setTimeBetweenEvictionRunsMillis(45 * 1000);\n setNumTestsPerEvictionRun(5);\n setMaxWaitMillis(30 * 1000);\n\n setMaxTotal(MAX_CONN);\n setMaxTotalPerKey(MAX_CONN);\n setMinIdlePerKey(MIN_IDLE_CONN);\n setMaxTotalPerKey(MAX_IDLE_CONN);\n\n setTestOnCreate(true);\n setTestOnBorrow(true);\n setTestWhileIdle(true);\n }\n\n @Override\n public TTransportPoolFactory getFactory() {\n return (TTransportPoolFactory) super.getFactory();\n }\n\n public void returnBrokenObject(K8ServiceKey key, TTransport transport) {\n try {\n invalidateObject(key, transport);\n } catch (Exception e) {\n LOG.warn(\"return broken key \" + key);\n e.printStackTrace();\n }\n }\n}\n```\n\n上述代码主要是完成连接池的配置，比较直观：\n1. 设置最大连接数1024\n1. 设置最大空闲数32，最小空闲数8，每间隔45秒尝试更改维护连接池中的连接数量。\n1. 当每次\"创建\"、从池子中\"借用\"、\"空闲\"时，检查连接是否有效。\n\n下面我们来看一下如何在K8ServiceThriftClient中使用：\n\n```java\npackage com.coder4.lmsia.thrift.client;\n\nimport com.coder4.lmsia.thrift.client.func.ThriftCallFunc;\nimport com.coder4.lmsia.thrift.client.func.ThriftExecFunc;\nimport com.coder4.lmsia.thrift.client.pool.TTransportPool;\nimport com.coder4.lmsia.thrift.client.pool.TTransportPoolFactory;\nimport org.apache.thrift.TServiceClient;\nimport org.apache.thrift.transport.TTransport;\n\npublic class K8ServiceThriftClient\n extends AbstractThriftClient {\n\n private K8ServiceKey k8ServiceKey;\n\n private TTransportPool connPool;\n\n @Override\n public void init() {\n super.init();\n // check\n if (k8ServiceKey == null) {\n throw new RuntimeException(\"invalid k8ServiceName or k8Serviceport\");\n }\n // init pool\n connPool = new TTransportPool(new TTransportPoolFactory());\n }\n\n @Override\n public TRET call(ThriftCallFunc tcall) {\n\n // Step 1: get TTransport\n TTransport tpt = null;\n K8ServiceKey key = getConnBorrowKey();\n try {\n tpt = connPool.borrowObject(key);\n } catch (Exception e) {\n throw new RuntimeException(e);\n }\n\n // Step 2: get client & call\n try {\n TCLIENT tcli = createClient(tpt);\n TRET ret = tcall.call(tcli);\n returnTransport(key, tpt);\n return ret;\n } catch (Exception e) {\n returnBrokenTransport(key, tpt);\n throw new RuntimeException(e);\n }\n }\n\n @Override\n public void exec(ThriftExecFunc texec) {\n // Step 1: get TTransport\n TTransport tpt = null;\n K8ServiceKey key = getConnBorrowKey();\n try {\n\n // borrow transport\n tpt = connPool.borrowObject(key);\n } catch (Exception e) {\n throw new RuntimeException(e);\n }\n\n // Step 2: get client & exec\n try {\n TCLIENT tcli = createClient(tpt);\n texec.exec(tcli);\n returnTransport(key, tpt);\n } catch (Exception e) {\n returnBrokenTransport(key, tpt);\n throw new RuntimeException(e);\n }\n }\n\n private K8ServiceKey getConnBorrowKey() {\n return k8ServiceKey;\n }\n\n private void returnTransport(K8ServiceKey key, TTransport transport) {\n connPool.returnObject(key, transport);\n }\n\n private void returnBrokenTransport(K8ServiceKey key, TTransport transport) {\n connPool.returnBrokenObject(key, transport);\n }\n\n public K8ServiceKey getK8ServiceKey() {\n return k8ServiceKey;\n }\n\n public void setK8ServiceKey(K8ServiceKey k8ServiceKey) {\n this.k8ServiceKey = k8ServiceKey;\n }\n\n}\n```\n\n上述大部分代码和EasyThriftClient非常接近，有差异的部分主要是与连接的\"借用\"、\"归还\"相关的：\n1. 在call和exec中，借用连接\n * getConnBorrowKey先构造一个key，包含了主机名和端口。这里的主机名是[微服务的自动发现](./ms-discovery/msd.md)中提到的Kubernetes服务，如果你对相关原理不太熟悉，可以自行回顾对应章节。\n * 从connPool中借用一个连接（TTransport）\n * 剩余发起rpc调用的步骤就和EasyThriftClient相同了，不再赘述。\n1. 当rpc调用结束后\n * 正常结束，调用connPool.returnObject将TTransport归还到连接池中。\n * 非正常结束，调用connPool.returnBrokenTransport，让连接池销毁这个连接，以防后续借用到这个可能出错的TTransport。\n\n类似的，我们也配套了对应的Builder：\n```java\npackage com.coder4.lmsia.thrift.client.builder;\n\nimport com.coder4.lmsia.thrift.client.EasyThriftClient;\nimport org.apache.thrift.TServiceClient;\n\n/**\n * @author coder4\n */\npublic class EasyThriftClientBuilder {\n\n private final EasyThriftClient client = new EasyThriftClient<>();\n\n protected EasyThriftClient build() {\n client.init();\n return client;\n }\n\n protected EasyThriftClientBuilder setHost(String host) {\n client.setThriftServerHost(host);\n return this;\n }\n\n protected EasyThriftClientBuilder setPort(int port) {\n client.setThriftServerPort(port);\n return this;\n }\n\n protected EasyThriftClientBuilder setThriftClass(Class thriftClass) {\n client.setThriftClass(thriftClass);\n return this;\n }\n}\n\n```\n\n上述Builder主要是设置所需的两个参数，Host和Port，看起来和EasyThriftClient并没有什么不同？\n\n别着急，我们继续看一下lmsia-abc-client中的集成：\n\n```java\npackage com.coder4.lmsia.abc.client;\n\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift;\nimport com.coder4.lmsia.abc.thrift.LmsiaAbcThrift.Client;\nimport com.coder4.lmsia.thrift.client.K8ServiceKey;\nimport com.coder4.lmsia.thrift.client.ThriftClient;\nimport com.coder4.lmsia.thrift.client.builder.K8ServiceThriftClientBuilder;\n\n/**\n * @author coder4\n */\npublic class LmsiaK8ServiceThriftClientBuilder extends K8ServiceThriftClientBuilder {\n\n public LmsiaK8ServiceThriftClientBuilder(K8ServiceKey k8ServiceKey) {\n setThriftClass(LmsiaAbcThrift.class);\n\n setK8ServiceKey(k8ServiceKey);\n }\n\n public static ThriftClient buildClient(K8ServiceKey k8ServiceKey) {\n return new LmsiaK8ServiceThriftClientBuilder(k8ServiceKey).build();\n }\n\n}\n\n```\n\n在集成的时候，我们需要传入一个key，可以手动制定，也可以自动配置\n\n我们看一下完整的自动配置代码，LmsiaAbcThriftClientConfiguration:\n\n```java\npublic class LmsiaAbcThriftClientConfiguration {\n\n @Bean(name = \"lmsiaAbcThriftClient\")\n @ConditionalOnMissingBean(name = \"lmsiaAbcThriftClient\")\n @ConditionalOnProperty(name = {\"lmsiaAbcThriftServer.host\", \"lmsiaAbcThriftServer.port\"})\n public ThriftClient easyThriftClient(\n @Value(\"${lmsiaAbcThriftServer.host}\") String host,\n @Value(\"${lmsiaAbcThriftServer.port}\") int port\n ) {\n LOG.info(\"######## LmsiaAbcThriftClientConfiguration ########\");\n LOG.info(\"easyThriftClient host = {}, port = {}\", host, port);\n return LmsiaAbcEasyThriftClientBuilder.buildClient(host, port);\n }\n\n @Bean(name = \"lmsiaAbcThriftClient\")\n @ConditionalOnMissingBean(name = \"lmsiaAbcThriftClient\")\n public ThriftClient k8ServiceThriftClient() {\n LOG.info(\"######## LmsiaAbcThriftClientConfiguration ########\");\n K8ServiceKey k8ServiceKey = new K8ServiceKey(K8_SERVICE_NAME, K8_SERVICE_PORT);\n LOG.info(\"k8ServiceThriftClient key:\" + k8ServiceKey);\n return LmsiaK8ServiceThriftClientBuilder.buildClient(k8ServiceKey);\n }\n\n //...\n\n}\n\n```\n\n对比easyThriftClient和k8ServiceThriftClient不难发现，K8ServiceThriftClient的参数，是通过常量直接写死的。也就是我们在[微服务的自动发现与负载均衡](../ms-discovery/msd.md)中提到的，约定好服务的命名规则。\n\n看下常量定义：\n```java\npublic class LmsiaAbcConstant {\n\n // ......\n\n public static final String PROJECT_NAME = \"lmsia-abc\";\n\n public static final String K8_SERVICE_NAME = PROJECT_NAME + \"-server\";\n\n public static final int K8_SERVICE_PORT = 3000;\n\n // ......\n}\n```\n\n这样以来，一旦确定了项目名，那么Kubernetes中的服务名字也确定了。因此，k8ServiceThriftClient自动配置会被自动激活，即只要引用了lmsia-abc-client这个包，就会自动配置好一个RPC客户端，是不是非常方便？\n\n我们来看一下具体的使用例子：\n\n```java\nimport com.coder4.lmsia.thrift.client.ThriftClient;\n\npublic class LmsiaAbctProxy {\n\n @Autowired\n private ThriftClient client;\n\n public String hello() {\n return client.call(cli -> cli.sayHi());\n }\n\n```\n\n至此，我们已经完成了在Spring Boo中集成Thrift RPC的服务端、客户端的工作。\n* 服务端，我们通过ThriftServerConfiguration、ThriftProcessorConfiguration自动配置了Thrift RPC服务端。\n* 客户端，通过Kubernetes的服务功能，自动配置了带服务发现功能的Thrift RPC客户端K8ServiceThriftClient。该客户端同时内置了连接池，用于节省连接开销。\n"
},
{
"path": "legacy/toolchain/README.md",
"content": "# 研发工具链\n\n子曰: \"工欲善其事必先利其器\"。\n\n本书的开篇已经指出，微服务的架构对研发人员提出了更高的要求。\n\n幸运的是，通过不断完善、改进研发工具链，可以为研发人员提供更高效、更便捷的开发环境。\n\n本书反复强调\"微服务\"、\"研发工具链\"、\"运维工具链\"三者是一个整体，如果只重视微服务的开发技术，而不重视工具链的建设，微服务的架构便无从谈起。\n\n本章将对微服务架构下，常见的研发工具进行介绍。\n\n大致又可分为两部分：\n* 研发环境构建: 主要包括内部帐号管理、代码版本管理、Java依赖管理，这些基础研发环境。\n* 高效研发构建: 主要通过小工具、代码模板、开源项目的引入，降低微服务开发难度，提升开发效率。\n\n现在，让我们开始研发工具链的构建之旅吧！\n"
},
{
"path": "legacy/toolchain/bom.md",
"content": "# BOM 减少版本冲突\n\n在应用了Gradle构建工具，以及Maven仓库来管理版本依赖后，程序的构建、依赖问题已经得到了基本的解决。\n\n但随着项目的不断发展，一个微服务的依赖可能会越来越多，出现版本冲突的问题。\n\n举个版本冲突的例子：项目依赖的A的0.9版本，同时依赖了项目B，项目B又依赖了项目A的1.0版本。此时，项目会选择A的0.9还是1.0版本呢？\n\n事实上，按照Maven的依赖规则，会选用最小的版本0.9。如果0.9和1.0是API兼容的，那么问题不大。如果1.0的API发生了\"break change\"，那么很遗憾，项目B中的代码会包错，更离谱的是，只有运行时才会发生问题。这类问题经常难以诊断，因此，我们应当尽量减少版本冲突的问题。\n\nBOM(Bill Of Materials)就是为了解决这个问题而生的，它定义了一组依赖管理的项目并约定了对应的版本。其他项目可以直接引用BOM而不用设定对应版本，BOM会自动把缺失的版本补全。\n\n在本书的微服务架构下，我们强烈建议定义公共库的BOM，以减少版本冲突的问题。\n\n应用BOM需要两个步骤:\n1. 新建一个BOM的Maven项目\n1. 在项目中引用该BOM项目\n\n新建一个BOM项目非常简单，只需要一个xml文件\n```xml\n\n\n 4.0.0\n\n com.coder4.lmsia\n pom-parent\n 0.0.4\n pom\n\n \n UTF-8\n 1.8\n \n\n \n \n \n org.springframework.boot\n spring-boot-dependencies\n 1.5.7.RELEASE\n pom\n import\n \n\t \n\t com.google.guava\n\t guava\n\t 23.0\n\t \n \n\t \n\t com.coder4.lmsia\n\t redis\n\t 0.0.4\n\t \n\t \n\t com.coder4.lmsia\n\t cache\n\t 0.0.5\n\t \n\t \n\t com.coder4.lmsia\n\t rabbitmq\n\t 0.0.2\n\t \n\t \n\t com.coder4.lmsia\n\t thrift-server\n\t 0.0.5\n\t \n\t \n\t com.coder4.lmsia\n\t database\n\t 0.0.1\n\t \n\t \n\t com.h2database\n\t h2\n\t 1.4.196\n\t \n \n \n \n\n \n \n nexus_coder4\n http://192.168.99.100:8081/nexus/content/repositories/releases/\n \n \n nexus_coder4\n http://192.168.99.100:8081/nexus/content/repositories/snapshots/\n \n \n\n```\n\n解释下上面的代码：\n1. 这是一个pom，应用了若干包，并指定了他们的版本\n1. 底部指定了maven仓库的发布地址(如果你有多个不同的maven repo权限才需要设定)\n\n然后看一下在gradle项目中如何引用bom:\n\nbuild.gradle:\n```\nplugins {\n id \"io.spring.dependency-management\" version \"1.0.3.RELEASE\"\n}\n\napply plugin: 'java'\napply plugin: 'application'\n\n\nrepositories {\n maven {\n credentials {\n username \"$mavenUser\"\n password \"$mavenPass\"\n }\n url 'http://maven.coder4.com/nexus/content/groups/public'\n }\n}\n\n// import bom\ndependencyManagement {\n imports {\n mavenBom 'com.coder4.sbmvt:pom-parent:0.0.1'\n }\n}\n\ndependencies {\n // use bom version\n compile 'org.springframework.boot:spring-boot-starter-web'\n compile 'com.coder4.lmsia:redis'\n // Use JUnit test framework\n testCompile 'junit:junit:4.12'\n}\n\n// Define the main class for the application\nmainClassName = 'App'\n\n```\n\n如上所示，我们通过dependencyManagement插件引入了bom项目，而指定项目时只有group和project、没有版本，版本会自动使用bom中统一定义的。\n\n对于微服务架构，我们可以将使用的数据库、RPC、消息队列、工具类等共用库的版本都放入BOM，以统一依赖的版本。\n"
},
{
"path": "legacy/toolchain/gerrit.md",
"content": "# gerrit 代码的版本管理与审查\n\n## 为什么选用git作为版本管理系统\n\n在实际工作中，绝大多数的项目都使用了代码的版本管理系统。在应用版本管理系统后，可以代码许多好处，相信大家有有所体会：\n* 团队合作: 应用版本管理系统后，每个团队成员都可以对每个文件进行修改，而不用担心出现不一致、改动丢失、甚至冲突的情况，版本管理系统会负责这些事情。\n* 改动可见: 项目开发往往不是一蹴而就，而是划分为许多个小步骤。我们可以将每个改动作为一次提交，版本管理系统可以展示出两个提交之间的差异，项目的开发进展一目了然。\n* 轻松回滚: 如果我们不小心搞出了一个bug，或者某个设计思路出现了较大错误，可以轻松的回滚到某个之前的版本，这也是版本管理系统为我们提供的便利功能。\n\n在版本系统的选型上，我们选用了git，相比于svn，它具有诸多优点：\n* 分布式、协作方便: git的设计就是分布式版本管理系统，更适用于多人协作。而svn设计理念就是中央式管理，中规中矩但不利于团队协作。\n* 速度更快: 在文件模式上，git基于\"指针式\"设计，比svn更快。在微服务架构下，创建新服务新项目更加频繁，git的速度优势会更加明显。\n* 分支切换: git的分支设计非常轻量级，完全可以在本地完成，而svn则需要完全拉取分支的所有文件，如果你使用svn管理过多分支的大项目，一定对此深有感触。\n* 操作更丰富：git提供了丰富的操作手段，当你使用熟练后，会比使用svn的效率更高。\n\n当然，git也有一个最大的缺点：学习曲线较为陡峭。对于新手而言，svn简单看看文档就能上手，git可能需要几天才能掌握基本操作。\n\n但是，面对git带给我们的种种好处，还是值得仔细学习一下的，篇幅所限，我们不会讨论git的用法。\n\n如果你想仔细学习，推荐阅读[廖雪锋的Git教程](https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000)。\n\n## 为什么代码需要代码审查\n\n如果是一个人做的开源项目，有版本管理系统就足够了。\n\n但对于团队开发，除了版本管理外，一般还应有代码审查(code review)。代码审查的优势如下：\n* 相互检查、提升质量: 在开发过程中，我们自己写出的bug，往往是看不出来的，换个人却很容易发现，就是所谓的\"当局者迷，旁观者清\"。通过相互检查代码，可以有效提升软件质量。\n* 让新成员快速提高: 我们希望新加入的团队成员，可以快速学习、快速成长。阅读项目固然是一个很好的方式，但一个项目往往太大，难以下手，代码审查的粒度是一次提交，更小、更适合新手学习。\n* 边开发边讨论: 在方案设计阶段，我们可能有了大致的方案，但在开发过程中，往往会暴露出更多的问题。代码审查为这些问题的讨论提供了一个合适的契机，大家可以在代码审核的同时进行讨论。\n\n在系统选型方面，我们选用了较为成熟的gerrit作为代码审查系统。\n\n需要指出的是gerrit同时内置了git服务器的功能，因此我们使用gerrit同时作为版本管理和代码审查系统。\n\n## gerrit系统的基本配置\n\n与之前的LDAP类似，我们也将gerrit部署在Kubernetes上。\n\n首先保证物理机上Volume挂载点的创建\n```shell\nminikube ssh\n\n$sudo mkdir /data/gerrit\n$sudo chown -R 999:999 /data/gerrit/\n```\n\n接着我们看一下deployment文件。\ngerrit-deployment.yaml\n```shell\npiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: gerrit-deployment\nspec:\n selector:\n matchLabels:\n app: gerrit\n replicas: 1\n template:\n metadata:\n labels:\n app: gerrit\n spec:\n restartPolicy: Always \n nodeSelector:\n kubernetes.io/hostname: minikube \n containers:\n - name: gerrit-ct\n image: openfrontier/gerrit:2.15.1\n ports:\n - containerPort: 8080\n hostPort: 80 \n - containerPort: 29418\n hostPort: 29418\n volumeMounts:\n - mountPath: \"/var/gerrit/review_site\"\n name: volume \n env:\n - name: GITWEB_TYPE\n value: gitiles\n - name: AUTH_TYPE \n value: LDAP\n - name: LDAP_SERVER \n value: ldap://192.168.99.100\n - name: LDAP_ACCOUNTBASE \n value: \"dc=coder4,dc=com\"\n - name: LDAP_ACCOUNTPATTERN\n value: \"(cn=${username})\"\n - name: LDAP_ACCOUNTSSHUSERNAME\n value: \"${cn}\"\n - name: LDAP_ACCOUNTFULLNAME\n value: \"${sn}\"\n - name: LDAP_USERNAME\n value: \"cn=guest,dc=coder4,dc=com\"\n - name: LDAP_PASSWORD\n value: \"guest123\"\n - name: WEBURL \n value: \"http://192.168.99.100\"\n volumes:\n - name: volume \n hostPath:\n path: /data/gerrit/\n```\n\n虽然文件很长，但并不复杂，我们简单解读下：\n* Docker镜像为openfrontier/gerrit:2.15.1\n* 端口映射8080到物理机的的80端口上\n* 挂载点/var/gerrit/review_site \n* 使用LDAP作为帐号接入，具体配置在之前LDAP一节已经见识过了，这里不再赘述。\n* WEB跳转URL定义为 http://物理机IP\n\n下面启动一下：\n```shell\nkubectl apply -f ./gerrit-deployment.yaml\n```\n\n启动成功后，我们访问gerrit，然后点击右上角的\"Sign In\"即可登录。这里的帐号，填写之前创建的一个LDAP内部帐号。需要特别说明的是，第一个登录的用户，会被gerrit认为是超级管理员，所以请慎重选择。\n\n![gerrit登录成功](./gerrit-login-succ.png \"gerrit登录成功j\")\n\n如果一切顺利的话，就会登录成功了。至此，我们已经完成了gerrit服务器的基本配置。\n\n## gerrit常用插件\n\ngerrit系统的基本功能比较简单，需要配合插件才能发挥出更大优势\n\n在此，我们先安装两个系统内置的插件：\n* commit msg长度检查\n* 项目下载url生成器\n\n安装插件是通过ssh命令完成的，一次，首先要将ssh密钥的公钥上传到gerrit上。\n\n如果你还没有ssh密钥，可以使用sshkeygen生成，这里不做详细展开。\n\n点击右上角的姓名 -> Settings -> SSH Public Keys，粘贴后点击\"Add\"。\n\n然后添加插件:\n```shell\nssh -p 29418 lihy@192.168.99.100 gerrit plugin install 'jar:file:/var/gerrit/review_site/bin/gerrit.war!/WEB-INF/plugins/download-commands.jar'\nssh -p 29418 lihy@192.168.99.100 gerrit plugin install 'jar:file:/var/gerrit/review_site/bin/gerrit.war!/WEB-INF/plugins/commit-message-length-validator.jar'\n```\n\n## gerrit项目的权限控制\n\ngerrit默认的权限配置是对所有人(包括注册用户和匿名用户)开放所有项目。\n\n这样的设置可能过为宽松，可以自行更改。\n\n使用管理员帐号登录，然后进入Projects -> All Projects，点击底部的顶部的\"Access\"，点击Edit。然后找到 Reference: refs/* -> Read，修改为 -> Block Anonymous Users，修改完成后点击\"Save for change\"。\n\n![修改匿名用户读权限](./gerrit-block-anonymous-users.png \"修改匿名用户读权限\")\n\n我们可以登出当前用户，再次访问gerrit主页，可以发现，在未登录状态，无法找到任何review和项目了。\n\n## 第一个gerrit代码review\n\n下面我们尝试用gerrit完成一个完整的流程:从新建项目、提交、到审核代码。\n\n我们尝试新建一个项目：Projects -> Create New Project:\n* 项目名为lmsia-xyz\n* 继承自All-Projects\n然后点击\"Create Project\"\n\n创建完成后，我们就可以将代码克隆到本地进行开发了。\n\n选择：Projects -> List 找到lmsia-xyz并点击，在顶部，可以找到Clone工具栏，选择右侧的ssh，底下会出现一行命令：\n```shell\ngit clone ssh://lihy@192.168.99.100:29418/lmsia-xyz\n```\n\n我们在本地执行这行命令，即可成功得克隆代码\n```shell\ngit clone ssh://lihy@192.168.99.100:29418/lmsia-xyz\nCloning into 'lmsia-xyz'...\nremote: Counting objects: 2, done\nremote: Finding sources: 100% (2/2)\nremote: Total 2 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (2/2), done.\nChecking connectivity... done.\n\n```\n\n如果报权限错误，一般是ssh密钥配置的不对，请检查gerrit个人资料中的key是否为本地设置的公钥。\n\n配置修改后，可以自行通过这条命令测试\n```shell\nssh -p 29418 lihy@192.168.99.100\n\n **** Welcome to Gerrit Code Review ****\n\n Hi 李赫元, you have successfully connected over SSH.\n\n Unfortunately, interactive shells are disabled.\n To clone a hosted Git repository, use:\n\n git clone ssh://lihy@192.168.99.100:29418/REPOSITORY_NAME.git\n\nConnection to 192.168.99.100 closed.\n\n```\n\n下面我们新建一个文件：\n```shell\ntouch README.md\n```\n\n添加并提交：\n```shell\ngit add .\n\ngit commit -m \"ADD: README.md\"\n```\n\n至此，我们已经完成了代码的提交，当然这只是提交到本地git仓库中。\n\n我们还需要推送到gerrit仓库中供别人审核。\n\n在可以推送到gerrit之前，还需要进行2个配置:\n1. (每台机器配置一次)若你的操作系统用户名和gerrit用户名一致，需要配置ssh选项。\n1. (每个项目配置一次)配置项目的gerrit远程仓库\n1. (每个项目配置一次)配置项目推送到gerrit后默认的代码审核人\n\n首先是ssh配置，以我的环境为例，我的操作系统用户名是coder4，而gerrit用户名是lihy，于是在~/.ssh/config中添加如下配置：\n```shell\nHost 192.168.99.100\n User lihy\n IdentityFile ~/.ssh/id_rsa\n Hostname 192.168.99.100\n Port 29418\n```\n这个配置并不复杂，就是告诉操作系统，当连接192.168.99.100这个host时，默认用户改为lihy而不是系统默认的coder4\n\n而上面每个项目需要执行一次的2和3稍微，这个操作稍微复杂一些，所以我将它合并成了一个脚本，方便大家调用。\n```shell\n#!/usr/bin/env bash\n\nGERRIT_HOST=\"192.168.99.100\"\nEMAIL_POSTFIX=\"coder4.com\"\n\nset -e\n\nfunction join { local IFS=\"$1\"; shift; echo \"$*\"; }\n\nif [ -z \"$1\" ]; then\n echo \"Usage: $0 reviewer[,reviewer ...]\"\n exit 1\nfi\n\nset -u\n\nif [ -z `git remote | grep origin` ]; then\n echo \"Remote origin not found, please clone this repository correctly or add origin remote by 'git remote add'.\"\n exit 1\nfi\n\nscp -p -P 29418 $GERRIT_HOST:hooks/commit-msg .git/hooks/\n\ncat > .git/hooks/pre-commit << EOF\n##!/bin/sh\nif git-rev-parse --verify HEAD >/dev/null 2>&1 ; then\n against=HEAD\nelse\n # Initial commit: diff against an empty tree object\n against=4b825dc642cb6eb9a060e54bf8d69288fbee4904\nfi\n# Find files with trailing whitespace\nfor FILE in \\`exec git diff-index --check --cached \\$against -- | sed '/^[+-]/d' | sed -E 's/:[0-9]+:.*//' | uniq\\` ; do\n # Fix them!\n sed -i '' -E 's/[[:space:]]*$//' \"\\$FILE\"\n git add \"\\$FILE\"\ndone\nEOF\nchmod a+x .git/hooks/pre-commit\n\noriginURL=`git remote -v | grep fetch | perl -nle'print $& if m{(?<=origin\\t)\\S*}'`\n\n(git remote remove review >& /dev/null || exit 0)\n\ngit remote add review $originURL\n\nIFS=',' read -a reviewers <<< \"$1\"\n\nsed -i '/\\+refs\\/heads\\/\\*:refs\\/remotes\\/review\\/\\*/d' .git/config\nfor i in \"${!reviewers[@]}\"; do\n reviewers[$i]=\"--reviewer=${reviewers[$i]}@$EMAIL_POSTFIX\"\ndone\necho -e \"\\tpush = HEAD:refs/for/master\" >> .git/config\necho -e \"\\treceivepack = git receive-pack `join \" \" ${reviewers[@]}`\" >> .git/config\n\n```\n如上的脚本做了3件事情:\n* 从gerrit上下载commit-msg的钩子，这是gerrit生成Change-ID所必须的。\n* 配置远程review仓库\n* 配置推送后默认的代码审核人\n\n执行一下，默认自己和张三审核：\n```shell\ninitGerrit.sh lihy,zhangsan\n```\n\n上述配置完成后，就可以推送你的第一个code review了：\n```shell\ngit push review\n\nCounting objects: 3, done.\nWriting objects: 100% (3/3), 244 bytes | 0 bytes/s, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nremote: Processing changes: refs: 1, done \nremote: ERROR: [127a929] missing Change-Id in commit message footer\nremote: \nremote: Hint: To automatically insert Change-Id, install the hook:\nremote: gitdir=$(git rev-parse --git-dir); scp -p -P 29418 lihy@192.168.99.100:hooks/commit-msg ${gitdir}/hooks/\nremote: And then amend the commit:\nremote: git commit --amend\nremote: \nTo ssh://lihy@192.168.99.100:29418/lmsia-xyz\n ! [remote rejected] HEAD -> refs/for/master ([127a929] missing Change-Id in commit message footer)\nerror: failed to push some refs to 'ssh://lihy@192.168.99.100:29418/lmsia-xyz'\n\n```\n\n然而我们发现还是执行失败，这是因为，我们先执行了commit后执行了initGerrit，导致commit时候没有Change-ID。\n\n我们可以按照提示补救一下：\n```shell\ngit commit --amend\n```\n\n再次执行推送，成功：\n```shell\ngit push review\nCounting objects: 3, done.\nWriting objects: 100% (3/3), 285 bytes | 0 bytes/s, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nremote: Processing changes: new: 1, done \nremote: \nremote: New Changes:\nremote: http://192.168.99.100/#/c/lmsia-xyz/+/21 ADD: README.md\nremote: \nTo ssh://lihy@192.168.99.100:29418/lmsia-xyz\n * [new branch] HEAD -> refs/for/master\n\n```\n\n我们到gerrit上看一眼，发现已经有了这个推送：\n\n![第一个review](./gerrit-first-review.png \"第一个review\")\n\n我们点击进去，自行+2，然后点击Submit，如下两图所示。\n\n![+2](./gerrit-p2.png \"代码审核+2\")\n![代码合并](./gerrit-submit.png \"代码合并\")\n\n此时，代码就被成功合并进master分支了。\n\n我们的gerrit默认配置了gitweb,即可以通过网页的方式查看项目的完整源码: Plugsin -> gitiles，界面如下图所示：\n\n![代码浏览](./gerrit-gittiles.png \"代码浏览\")\n\n通过选择不同项目，可以查看不同分支的完整代码。\n\n至此，我们完成了Gerrit服务的搭建，并通过完整的例子演示了项目的创建、克隆、开发、提交、审核流程。\n\nGerrit还有很多强大的功能，例如Web上可以创建分支、Rebase代码等等，如果你想探索这些高级用法，可以参考[官方文档](https://gerrit-documentation.storage.googleapis.com/Documentation/2.15.2/index.html)。\n"
},
{
"path": "legacy/toolchain/kanboard.md",
"content": "# Kanboard Scrum看板\n\n"
},
{
"path": "legacy/toolchain/ldap.md",
"content": "# LDAP 内部账号管理系统\n\n## LDAP及其必要性 \n\n对于任何一个研发团队，一套内部通用的帐号管理系统都是必不可少的。请注意我的用词:\"内部通用\"。\n\n公司内部可能有各种系统：\n* 行政层面的OA系统、邮件系统、会议室预订系统。\n* 研发团队内部又可能有代码管理、项目进度管理、Bug追踪、依赖管理、Wiki等等。\n\n如果没有内部通用帐号，那么每来一个新员工，就需要到上述所有系统中，分别注册一次。想象一下，这是多么让人头疼的事情！\n\n因此，我们建议团队一定要拥有一套\"内部通用\"的帐号管理系统。\n\n在这里，我们选用了LDAP(Lightweight Directory Access Protocol)。是一个开放的，中立的，工业标准的应用协议，通过IP协议提供访问控制和维护分布式信息的目录信息。\n\n在技术型团队中，LDAP可以当作内部帐号管理系统来使用。此外，LDAP可以很轻松地与其他系统对接，我们后面即将构建的代码管理、版本管理，都将通过LDAP帐号接入。\n\n\n## OpenLDAP服务的初步配置\n\n能提供LDAP服务的开源项目有很多，我们选用了较为成熟的开源服务器OpenLDAP。\n\n虽然OpenLDAP并不是微服务，但我们依然放到Kubernetes集群部署，主要原因是：\n* 方便运维: 如果不用Docker，就需要手动的安装、配置。一旦物理服务器发生故障，需要迁移服务时，就需要重新执行这些操作。运维起来非常麻烦。\n* 方便备份与恢复: 对于这类帐号系统，可用性倒要求并不高(偶尔挂掉1个小时，能接受)，但是对数据安全性，特别是备份有较高要求。使用Docker后，我们只需要将产生的数据挂载到Volume上，然后定期备份Volume即可。\n\n\n来看一下部署文件openldap-deployment.yaml:\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: openldap-deployment\nspec:\n selector:\n matchLabels:\n app: openldap\n replicas: 1\n template:\n metadata:\n labels:\n app: openldap\n spec:\n restartPolicy: OnFailure \n nodeSelector:\n kubernetes.io/hostname: minikube \n containers:\n - name: openldap-ct\n image: osixia/openldap:1.1.9 \n ports:\n - containerPort: 389\n hostPort: 389 \n - containerPort: 636\n hostPort: 636 \n volumeMounts:\n - mountPath: \"/etc/ldap/slapd.d\"\n name: volume \n subPath: conf\n - mountPath: \"/var/lib/ldap\"\n name: volume\n subPath: data\n env:\n - name: LDAP_TLS \n value: \"false\"\n - name: LDAP_DOMAIN \n value: \"coder4.com\"\n - name: LDAP_ADMIN_PASSWORD \n value: \"admin123\"\n - name: LDAP_READONLY_USER \n value: \"true\"\n - name: LDAP_READONLY_USER_USERNAME\n value: \"guest\"\n - name: LDAP_READONLY_USER_PASSWORD \n value: \"guest123\"\n volumes:\n - name: volume \n hostPath:\n path: /data/openldap/\n```\n\n这是一个很长的文件，我们来逐条解释下：\n* restartPolicy: 虽然这是一个内部服务，但我们还是希望它能稳定提供服务。如果万一服务挂掉，希望能自动重启。因此我们设置自动重启策略为OnFailure。\n* nodeSelector: 我们强制选择了主机名。即这个Pod只能启动在minikube这台hostname的主机上，为什么呢？因为我们的OpenLDAP服务使用了本地Volume(hostVolume)，如果不固定机器，允许Pod在任意物理机启动的话，对应Volume并不会自动迁移，导致之前的账户信息\"丢失\"。因此，对于需要使用Volume的服务，要么选择一种可自动迁移的Volume，要么就需要绑定到一台物理机上。如果你想选用自动迁移的Volume，可以参考[官方Volumes文档](https://kubernetes.io/docs/concepts/storage/volumes/)。\n* ports: 我们直接对集群外暴露了389和636两个端口。在实际生产中，我建议选择一台独立的物理机部署所有的内部服务(ldap、maven、git等)。为什么这样搞呢？如果物理机是固定的，我们可以给它分配一个固定的办公网IP，甚至固定的办公网DNS域名，然后简单地通过暴露端口的方式，就可以对全部办公网提供服务了。\n* volumeMounts & volumes: 定义了两个volume挂载点，分别挂载到容器的/etc/ldap/slapd.d(配置)和/var/lib/ldap(数据)目录上。对应的物理机挂载目录在/data/openldap/conf和/data/openldap/data上。\n* env: 通过环境变量完成了一些初始化的设定，具体如下。\n * 不用加密协议[^1]\n * 设置域为coder4.com，可以根据你的需求自行更改。\n * 创建系统管理员帐号，密码是admin123，这是一个超级管理员，对应用户名是admin(无法更改)\n * 创建系统只读帐号，用户名和密码是guest/guest123。这主要是用于其他服务与OpenLDAP服务的通信，只能读取、验证信息，不能做任何更改。\n\n在部署前，我们先要保证物理机上的挂载点存在。\n```shell\nminikube ssh\n$ cd /data\n$ sudo mkdir openldap\n```\n\n然后部署OpenLDAP服务：\n```shell\nkubectl apply -f ./openldap-deployment.yaml\n```\n\n查看下状态，启动成功了：\n```shell\nkubectl get pods\n\nNAME READY STATUS RESTARTS AGE\nopenldap-deployment-7d6b7875f-hxqxf 1/1 Running 0 14m\n\n```\n\n获取集群的IP：\n```shell\nminikube ip\n\n192.168.99.100\n```\n\n验证下，端口已经成功暴露给了集群外：\n```shell\ntelnet 192.168.99.100 389\nTrying 192.168.99.100...\nConnected to 192.168.99.100.\nEscape character is '^]'.\n^]\n\n```\n\n操作ldap集群，需要安装一些工具，以Ubuntu为例：\n```shell\nsudo apt-get install ldap-utils\n```\n\n有了工具后，两个系统帐号已经创建成功：\n```shell\nldapwhoami -h 192.168.99.100 -p 389 -D \"cn=admin,dc=coder4,dc=com\" -w admin123\n\ndn:cn=admin,dc=coder4,dc=com\n\nldapwhoami -h 192.168.99.100 -p 389 -D \"cn=guest,dc=coder4,dc=com\" -w guest123\n\ndn:cn=guest,dc=coder4,dc=com\n```\n\n至此，我们已经完成了OpenLDAP的基础配置，并且成功创建了两个系统帐号。\n\n\n## 创建内部用户\n\n在刚才的配置中，我们创建了两个系统帐号，但在实际工作中，团队成员一般不会使用系统帐号。\n\n对于一个团队成员，它的帐号至少需要有如下属性：\n* 用户名, 一般是纯英文、拼音缩写\n* 中文姓名，这个不解释了\n* 密码，最好不是明文，而是加密存储\n* 邮箱，公司内部的电子邮箱地址\n\n大公司的内部，会细分为多个团队，此时还应当将用户划分到相应的属组。由于篇幅所限，我们在此不讨论属组的问题。\n\n\n在密码加密方面，我们采用ssha，它需要命令slappasswd，你可以在任何安装了openldap的机器上找到它：\n```shell\nslappasswd -h {ssha} -s pass123\n\n{SSHA}yG3DQj7iol10+fzWoeBAgoZ+D+h9uQre\n```\n\n上述即生成了一个ssha加密过的密码pass123。\n\n我们前面已经提到，LDAP是一个\"目录式\"的权限管理服务。其本身规则非常复杂到可以单独写一本书:-)\n\n本书不会对其规则进行过多讲解，这里先提供了一个简单的模板，供大家学习。\n\n./users.ldif\n```shell\nversion: 1\n\n# users org\ndn: ou=users,dc=coder4,dc=com\nobjectClass: top\nobjectClass: organizationalUnit\nou: users\n\n# group org\ndn: ou=groups,dc=coder4,dc=com\nobjectClass: top\nobjectClass: organizationalUnit\nou: groups\n\n# define users here\ndn: cn=lihy,ou=users,dc=coder4,dc=com\nobjectClass: top\nobjectClass: person\nobjectClass: organizationalPerson\nobjectClass: inetOrgPerson\ncn: lihy\nsn:: 5p2O6LWr5YWD\nmail: lihy@coder4.com\nuserPassword: {SSHA}yG3DQj7iol10+fzWoeBAgoZ+D+h9uQre \n\ndn: cn=zhangsan,ou=users,dc=coder4,dc=com\nobjectClass: top\nobjectClass: person\nobjectClass: organizationalPerson\nobjectClass: inetOrgPerson\ncn: zhangsan \nsn:: 5byg5LiJ\nmail: zhangsan@coder4.com\nuserPassword: {SSHA}yG3DQj7iol10+fzWoeBAgoZ+D+h9uQre\n\n# should also modify here if insert new user\ndn: cn=Users,ou=groups,dc=coder4,dc=com\nobjectClass: top\nobjectClass: groupOfUniqueNames\ncn: Users\nuniqueMember: cn=lihy,ou=users,dc=coder4,dc=com\nuniqueMember: cn=zhangsan,ou=users,dc=coder4,dc=com\n\n# define admin here\ndn: cn=Admin,ou=groups,dc=coder4,dc=com\nobjectClass: top\nobjectClass: groupOfUniqueNames\ncn: Admin\nuniqueMember: cn=lihy,ou=users,dc=coder4,dc=com\n\n```\n\n简单解释下：\n* 我们创建了2个组users和groups，前者存放用户，后者表示用户的属组。\n* 定义两个用户lihy和zhangsan，他们的密码用前面提到的SSLA加密\n* 将两个用户加入Users组内\n* 将lihy用户加入管理员组内\n\n\n我们来应用这个模板：\n```shell\nldapadd -c -h 192.168.99.100 -p 389 -w admin123 -D \"cn=admin,dc=coder4,dc=com\" -f ./users.ldif\n```\n\n如上，需要用admin帐号，-c选项是忽略所有错误，继续执行。\n\n验证一下新增的内部用户：\n```shell\nldapwhoami -h 192.168.99.100 -p 389 -D \"cn=lihy,ou=users,dc=coder4,dc=com\" -w pass123\n\ndn:cn=lihy,ou=users,dc=coder4,dc=com\n```\n\n添加新用户，需要操作三个步骤：\n1. 在user.idlf中增加用户的定义\n1. 在user.idlf对应属组中添加\n1. 执行ldapadd命令\n\n## LDAP系统管理脚本\n\n不用我说大家也明白，上述步骤真的是非常繁琐，而且容易出错。\n\n面对这种情况，大家可以选用第三方的工具来管理LDAP帐号，例如phpLDAPadmin，但是这需要额外维护一套系统，不免有些笨重。\n\n为了降低维护成本，我提供了几个简单的小脚本，以满足日常的管理工作。\n\n添加帐号，ldap_add.sh\n```shell\n#!/bin/bash\n\n# const\nLDAP_SERVER_IP=\"192.168.99.100\"\nLDAP_SERVER_PORT=\"389\"\nLDAP_ADMIN_USER=\"cn=admin,dc=coder4,dc=com\"\nLDAP_ADMIN_PASS=\"admin123\"\n\nif [ x\"$#\" != x\"3\" ];then\n echo \"Usage: $0 \"\n exit -1\nfi\n\n# param\nUSERNAME=\"$1\"\nPASSWORD=\"$2\"\nENCRYPT_PASSWORD=$(slappasswd -h {ssha} -s \"$PASSWORD\")\nREALNAME=\"$3\"\nREALNAME_BASE64=$(echo -n $REALNAME | base64)\n\n# add count & group \ncat < \"\n exit -1\nfi\n\n# param\nUSERNAME=\"$1\"\nPASSWORD=\"$2\"\nENCRYPT_PASSWORD=$(slappasswd -h {ssha} -s \"$PASSWORD\")\n\n# modify\ncat <\"\n exit -1\nfi\n\n# param\nUSERNAME=\"$1\"\n\n# delete user \nldapdelete -c -h $LDAP_SERVER_IP -p $LDAP_SERVER_PORT -w $LDAP_ADMIN_PASS -D $LDAP_ADMIN_USER \"cn=$USERNAME,ou=users,dc=coder4,dc=com\"\n\n```\n\n尝试删除一下：\n```shell\n./ldap_delete.sh zhangsan\n```\n\n然后验证下，确实无法登录了\n```shell\nldapwhoami -h 192.168.99.100 -p 389 -D \"cn=zhangsan,ou=users,dc=coder4,dc=com\" -w pass123\nldap_bind: Invalid credentials (49)\n```\n\n至此，我们完成了LDAP服务的构建，并可以通过简单的脚本完成帐号的添删改操作。\n\n[^1]: 如果你十分看中帐号服务对外通信的安全性，建议还是开启，具体可以参考[docker-openldap](https://github.com/osixia/docker-openldap))\n"
},
{
"path": "legacy/toolchain/nexus.md",
"content": "# Nexus 私有maven仓库\n\n依赖管理是技术栈的重要一环，几乎所有的现代编程语言都拥有自己的依赖管理系统。\n\n如果你在很久以前就从事了Java开发，或者参与过一些\"不太正规\"的项目，一定经历有过\"jar包随便拷、jar包满天飞\"的经历。在这种情况下，每次上线发布、升级jar包都是非常痛苦的事情。\n\n大概从2003年开始，构建工具逐渐走入Java开发者的视野，Maven是构建工具中应用最为广泛的工具之一，它在提供构建功能的同时，也自带了强大的依赖管理功能。采用maven后，我们只需要定义xml就可以自动下载依赖的jar包，而不需要\"手动将jar包拷来拷去\"。\n\n近几年来，作为一种更高效的构建工具 - Gradle - 逐渐崛起，在一些开发领域(如Android)，Gradle已经完全取代了Maven成为事实上的构建标准。\n\n尽管从构建工具的角度而言，Maven的地位有所下降，但它在Java依赖管理子领域的地位却不容撼动。Gradle默认也是直接采取Maven的依赖管理框架(只不过换为更简便的描述语言)。\n\n在[架构概览](architecture/README.md)一章中，我们已经说明：在选型上，我们使用Gradle作为构建工具，但依然采用Maven来管理依赖。\n\n在Maven的依赖管理方面，我们将使用Nexus搭建私有Maven服务器。为什么要搭建私服呢？\n\n这和为什么搭建私有Git服务器却不用GitHub公开仓库是一个道理：没有公司愿意将自己的代码暴露给全世界:-)\n\n## Nexus仓库的基本配置\n\n与前两节类似，我们首先在Kubernetes上部署Nexus服务。\n\n创建之前，先在物理机上创建Volume挂载点:\n```shell\nminikube ssh\n\n$sudo mkdir /data/nexus\n$sudo chmod -R 777 /data/nexus/\n```\n\n这里因为nexus需要有一个文件锁，默认权限是不够的，我们给了777权限，如果你觉得过于宽松，可以自行更改Kubernetes的启动用户，并设定相应权限。\n\n看一下部署文件, nexus-deployment.yaml:\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: nexus-deployment\nspec:\n selector:\n matchLabels:\n app: nexus\n replicas: 1\n template:\n metadata:\n labels:\n app: nexus\n spec:\n restartPolicy: Always \n nodeSelector:\n kubernetes.io/hostname: minikube \n containers:\n - name: nexus-ct\n image: sonatype/nexus:2.14.8\n ports:\n - containerPort: 8081\n hostPort: 8081 \n volumeMounts:\n - mountPath: \"/sonatype-work\"\n name: volume \n volumes:\n - name: volume \n hostPath:\n path: /data/nexus/\n```\n\n部署一下:\n```shell\nkubectl apply -f ./nexus-deployment.yaml\n```\n\n一切顺利的话，稍等一会访问\"http://192.168.99.100:8081/nexus\"，部署成功，如下图所示:\n\n![nexus部署成功](./nexus-welcome.png \"nexus部署成功\")\n\n## Nexus接入LDAP帐号\n\n服务虽然好了，但还没有接入LDAP帐号系统，Nexus中接入LDAP帐号较为繁琐，请耐心操作完。\n\n首先，设置一下LDAP的连接配置。\n\n1. 使用默认管理员帐号登录，用户名admin，密码admin123\n1. 点击左侧菜单\"Security\" -> \"LDAP Configuration\"\n1. 设置LDAP配置如下\n 1. Protocol: ldap\n 1. Hostname: 192.168.99.100\n 1. SearchBase: dc=coder4,dc=com\n 1. Authentication Method: Simple Authentication\n 1. Username: cn=guest,dc=coder4,dc=com\n 1. Password: guest123\n 1. Base DN: ou=users\n 1. Object Class: inetOrgPerson\n 1. User ID Attribute: cn\n 1. Real Name Attribute: sn\n 1. E-Mail Attribute: mail\n 1. Group Element Mapping: 不选中\n\n上述配置稍显繁琐，请耐心完成。都配置完成后，点击\"Save\"。\n\n此外，点击底部的\"Check User Mapping\"，如果一切配置正确，可以展示所有的列表，如下图所示。\n\n![nexus配置ldap帐号接入](./nexus-ldap-config.png \"nexus配置ldap帐号接入\")\n\n第二步，下面我们来更改默认认证方式为LDAP。\n\n点击左侧菜单\"Administration\" -> \"Server\"，进行如下配置:\n1. 在Security Settings中，将右侧的\"OSS LDAP Authentication Realm\"加入到左边，并将其拖动到最顶部。\n1. 取消勾选\"Anoymous Access\"。\n\n![配置认证方式为LDAP](./nexus-auth-config.png \"配置认证方式为LDAP\")\n\n配置可以参考上图，设置好后，点击\"Save\"。\n\n最后，我们需要对所有用户配置权限，注意，每次LDAP新接入用户后，都要执行下述操作。\n\n点击左侧菜单\"Security\" -> \"Users\" ，执行下述操作:\n1. 点击\"All Configured Users\"旁边的小箭头，选择\"LDAP\"\n1. 点击\"Refresh\"，此时就能拿到所有LDAP中的用户了。\n1. 选中一个要操作的用户，例如\"lihy\"，选择底部的\"Config\"，然后\"Role Management\"。\n1. 一般用户给\"Nexus Deployment Role\"就可以了，管理员可以给\"Nexus Administrator Role\"。\n1. 设置好后点击\"Save\"\n\n![nexus给用户权限](./nexus-role.png \"nexus给用户权限\")\n\n一个配置好的结果如上图所示。\n\n至此，我们已经成功接入了LDAP，试着用配置好的用户登录下，发现可以登录成功。\n\n## 配置Nexus中央仓库的缓存\n\nMaven依赖仓库也是分布式，我们最长用的，是\"Maven Central\"这个中央仓库。\n\n我们建议将中央仓库的索引缓存到Nexus私服上，这大约需要20GB的空间。\n\n使用管理员帐号登录后，点击左侧菜单\"View/Repositories\":\n1. 选择\"Repositories\"\n1. 在右侧选择\"Central\"这个仓库\n1. 底部\"Configuration\"配置\n 1. Remote Storage Location: http://maven.aliyun.com/nexus/content/repositories/central/ (这里我们使用了阿里云的国内镜像以加快速度) \n 1. Download Remote Indexes: True\n1. 最后点击底部的\"Save\"\n\n![nexus私服配置maven中央仓库缓存](./nexus-maven-central-cache.png \"nexusa中央仓库缓存配置\")\n\n缓存的时间比较长，在我的虚拟机上，花费了20分钟。进度可以在这里查看，左侧菜单\"Administration\" -> \"Logging\" 选择Log, 可以看到目前还在缓存:\n```shell\n2018-05-28 08:40:19,792+0000 INFO [pxpool-1-thread-1] admin org.sonatype.nexus.index.DefaultIndexerManager - Trying to get remote index for repository \"Central\" [id=central]\n```\n\n等缓存成功后，在本地仓库的\"Browse Index中\"，应当能看到与中央仓库一样的目录结构，如下图所示：\n\n![nexus私服中查看中央仓库结构](./nexus-maven-central-cache.png \"nexus私服中查看仓库结构\")\n\n至此，我们成功架设了基于Nexus的Maven私有仓库，集成了LDAP登录，并缓存了Maven中央仓库。\n\n## 如何在Gradle中应用私有仓库\n\n在配置了私有仓库后，我们还需要在微服务项目中启用这个私有仓库。\n\n这大致需要2步\n1. 配置maven私有仓库用户名和密码\n1. build.gradle中配置\n\n下面我们分别看一下\n\n## 配置Maven私有仓库用户名和米按摩\n\n```shell\nvim ~/.m2/settings.xml\n\n# 新增如下内容\n\n \n \n nexus_coder4\n lihy\n pass\n \n \n \n \n \n nexus_coder4\n central\n http://192.168.99.100:8081/content/groups/public\n \n \n \n \n nexus_coder4\n \n \n \n central\n http://192.168.99.100:8081/content/groups/public\n true\n true\n \n \n \n \n central\n http://192.168.99.100:8081/content/groups/public\n true\n true\n \n \n \n \n \n nexus_coder4\n \n\n\n```\n如上，我们新增了私有仓库的地址、用户配置，如果你觉得在文件中直接\"裸写\"密码不安全，可以参考[maven密码加密方法](https://maven.apache.org/guides/mini/guide-encryption.html#How_to_encrypt_server_passwords)。\n\n下面，我们在build.gradle中配置：\n```build.gradle\nbuildscript {\n\n repositories {\n maven { url 'http://maven.aliyun.com/nexus/content/groups/public' }\n maven { url 'https://jitpack.io' }\n }\n\n dependencies {\n // version just for plugin, not important\n classpath(\"org.springframework.boot:spring-boot-gradle-plugin:1.5.6.RELEASE\")\n }\n}\n\nsubprojects {\n\n apply plugin: 'java'\n apply plugin: 'idea'\n apply plugin: 'maven'\n apply plugin: 'org.springframework.boot'\n\n sourceCompatibility = 1.8\n targetCompatibility = 1.8\n\n group = 'com.coder4.lmsia'\n version = '0.0.1'\n\n repositories {\n maven {\n credentials {\n username \"$mavenUser\"\n password \"$mavenPass\"\n }\n url 'http://192.168.99.100:8081/nexus/content/groups/public'\n }\n mavenLocal()\n }\n\n // maven deploy config start\n configurations {\n deployerJars\n }\n\n uploadArchives {\n repositories.mavenDeployer {\n configuration = configurations.deployerJars\n repository(url: \"http://192.168.99.100:8081/nexus/content/repositories/releases/\") {\n authentication(userName: \"$mavenUser\", password: \"$mavenPass\")\n }\n snapshotRepository(url: \"http://192.168.99.100:8081/nexus/content/repositories/snapshots/\") {\n authentication(userName: \"$mavenUser\", password: \"$mavenPass\")\n }\n }\n }\n\n // maven deploy config end\n\n}\n```\n\n如上，build.gradle主要进行如下配置:\n* 子项目的仓库，采用私有仓库\n* 子项目发布包时，也发布到私有仓库上\n\n至此，我们成功地将maven私有仓库应用到了gradle的微服务上。\n"
},
{
"path": "legacy/toolchain/spring-boot-scripts.md",
"content": "# 懒人脚本\n\n"
},
{
"path": "legacy/toolchain/spring-boot-template.md",
"content": "# Spring Boot 项目模板\n\n"
},
{
"path": "legacy/toolchain/stress-test.md",
"content": "# 打压工具\n\n当业务刚刚起步的时候，微服务的稳定性是我们的首要保障目标，即服务能否稳定运行而不会挂掉。\n\n随着业务逐渐发展，用户数据量不断增大，并发的请求数也会不断加大。慢慢地，性能问题也会逐渐暴露出来。\n\n典型的性能问题有:\n1. 服务响应变慢\n1. 并发请求过多，导致数据库连接打满，无法访问数据库\n1. 流量过大，带宽被打满\n\n想要解决性能问题，先要能客观的评价性能，例如：在100个并发用户的前提下，我们的服务每秒能处理多少请求？\n\n要评估这类性能问题，就需要做一些性能压测。\n\n性能打压工具可以大致分为两类：\n1. 在UI界面配置完成打压，如JMeter、Tsung等\n1. 需要写代码完成打压，如Gatling、Locust等\n\n对于JMeter等工具，虽然上手简单，但是可定制程度较低，一些复杂的规则和参数配置起来很繁琐，一般由测试人员做简单打压时使用。\n而Locust等工具，虽然需要写代码，但了都提供了简化的API，编写起来非常简单，而且可以适应复杂的业务需求。\n\n综上所述，我们选用代码类打压工具。\n\nGatling性能很好，但只支持Scala语言；Locust是Python语言开发的，可以支持多种编程语言。在本书中，我们将分别介绍这两款打压工具。\n\n## 暴露服务端口\n\n在介绍打压工具前，我们先要对服务进行一些变更，让服务能够从集群外访问到。\n\n在[Spring Boot整合REST服务](spring-boot-1/sb-rest.md)章节中，我们配置了基于Kubernetes的REST服务，并设置了虚拟IP、虚拟IP的8080端口负责多结点的负载均衡。但是，虚拟IP默认只在集群内部生效。\n\n当我们需要将Kubernetes服务暴露给集群外时，一般有如下选择:\n* 为Service添加NodePort\n* 为Service添加ClusterIP\n* 增加Nginx反向代理，并为Nginx添加上述外部暴露的端口\n\n在这里，我们采用第一种方式，如果你想了解其他方式，可以参考[Publising Service](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)\n\n看一下更新的service描述文件\n```yaml\napiVersion: v1 \nkind: Service\nmetadata: \n name: lmsia-abc-server-service\nspec: \n selector: \n app: lmsia-abc-server\n type: NodePort\n ports: \n - name: http\n protocol: TCP \n port: 8080 \n nodePort: 30888\n - name: rpc\n protocol: TCP \n port: 3000\n nodePort: 30999\n\n```\n\n与之前的文件相比，上述yaml描述主要是增加了NodePort的定义和描述。\n* http端口对外暴露的是30888\n* rpc端口对外暴露的是30999\n\n我们应用下配置变更:\n```shell\nkubectl apply -f lmsia-abc-server-service-node-port.yaml\n```\n\n\n然后尝试访问，可以成功访问:\n```shell\ncurl http://192.168.99.100:30888/lmsia-abc/api/\n\nHello, REST\n```\n\n## Locust打压工具\n在你的开发机上安装\n```shell\npip install locustio\n```\n\n下面我们来看打压脚本hello.py:\n\n```python\nfrom locust import HttpLocust, TaskSet, task\n\nimport resource\nresource.setrlimit(resource.RLIMIT_NOFILE, (999999, 999999))\nprint resource.getrlimit(resource.RLIMIT_NOFILE)\n\nclass TestSet(TaskSet):\n @task(1)\n def hello(self):\n self.client.get(\"/lmsia-abc/api/\")\n\nclass WebsiteUser(HttpLocust):\n task_set = TestSet\n min_wait = 5000\n max_wait = 9000\n\n```\n\n上面的代码非常简单，就是访问地址\"/lmsia-abc/api/\"。\n\n下面来运行打压工具\n```\nlocust -f hello.py --host=http://192.168.99.100:30888\n```\n\n启动后，访问localhost:8089，会进入如下界面：\n\n![Locust选择用户数](./locust-swarm.png \"Locust选择用户数\")\n\n上面是设置最终多少并发，下面是设置用户增长的速度（每秒新增多少）。\n\n我们这里分别设置1000和200，然后点击开始。\n\n之后会进入打压进度页面，如下图所示：\n\n![Locust打压进度](./locust-progress.png \"Locust打压进度\")\n\n点击\"Charts\"，可以看到随着用户数变化，响应时间、QPS的变化曲线，如下图：\n\n![Locust打压变化](./locust-charts.png \"Locust打压变化\")\n\n打压结束后，点击\"STOP\"即可。\n\n除了单击打压外，Locust还支持分布式打压，即可以启动若干个节点共同完成打压作业，具体可以参考官方文档[Running Locust distributed](https://docs.locust.io/en/stable/running-locust-distributed.html)。\n\n## Gatling打压工具\n\n首先，到[官网](https://gatling.io/download/)下载最新版的gatling：\n\n```shell\nhttps://repo1.maven.org/maven2/io/gatling/highcharts/gatling-charts-highcharts-bundle/2.3.1/gatling-charts-highcharts-bundle-2.3.1-bundle.zip\n```\n\n然后解压缩到本地路径:\n```shell\nunzip gatling-charts-highcharts-bundle-2.3.1.zip\n\nmv gatling-charts-highcharts-bundle-2.3.1 gatling\n```\n\n然后看一下打压脚本:\n```scala\nimport io.gatling.core.Predef._ \nimport io.gatling.http.Predef._\nimport scala.concurrent.duration._\n\nclass HelloSimulation extends Simulation {\n\n val httpConf = http \n .baseURL(\"http://192.168.99.100:30888\") \n\n val scn = scenario(\"HelloSimulation\").during(30) {\n exec(http(\"hello_1\")\n .get(\"/lmsia-abc/api/\"))\n }\n\n setUp(\n scn.inject(atOnceUsers(2000))\n ).protocols(httpConf)\n}\n\n```\n\n如上，Gating的打压脚本稍微复杂一些:\n* 服务根地址192.168.99.100:30888\n* 访问的get请求\"/lmsia-abc/api/\"\n* 并发2000个用户\n\n执行一下打压：\n```shell\ngatling.sh -sf . -s HelloSimulation\n```\n\n结果中可以直接看到各项统计结果：\n```shell\n---- Global Information --------------------------------------------------------\n> request count 353505 (OK=353505 KO=0 )\n> min response time 0 (OK=0 KO=- )\n> max response time 1644 (OK=1644 KO=- )\n> mean response time 170 (OK=170 KO=- )\n> std deviation 122 (OK=122 KO=- )\n> response time 50th percentile 143 (OK=143 KO=- )\n> response time 75th percentile 219 (OK=219 KO=- )\n> response time 95th percentile 408 (OK=408 KO=- )\n> response time 99th percentile 606 (OK=606 KO=- )\n> mean requests/sec 11047.031 (OK=11047.031 KO=- )\n---- Response Time Distribution ------------------------------------------------\n> t < 800 ms 353348 (100%)\n> 800 ms < t < 1200 ms 148 ( 0%)\n> t > 1200 ms 9 ( 0%)\n> failed 0 ( 0%)\n================================================================================\n\nReports generated in 2s.\n\n```\n\nGating的打压工具功能更为强大，具体可以参考官方教程[Gatling UserGuides](https://gatling.io/docs/2.3/)\n"
},
{
"path": "src/README.md",
"content": "# 从0到1实战微服务架构(第2版)\n\n## 地址汇总\n\n* [Github项目 求Star:-)](https://github.com/liheyuan/hands-on-microservices)\n* [在线阅读](https://coder4.com/homs_online/)\n\n## 第2版前言\n\n自从本书发布了后，技术圈发生了许多变化：\n\n* Spring Boot 2.X 稳定版发布\n* Kubernetes下的包管理项目“Helm”，正式加入CNCF基金会\n* 阿里巴巴开源了Nacos服务发现项目\n* ......\n\n3年后的2021年，我正式开启了本书2.0版的写作计划。\n\n由于技术更新迭代频繁，这是一次完全的重写，不是修订。\n\n由于gitbook项目已不再维护，我改用[mdBook](https://github.com/rust-lang/mdBook)做为渲染工具，[MarkText](https://github.com/marktext/marktext)做为写作工具。\n\n写作水平有限，还请各位多提宝贵意见。\n\n## 第1版前言\n\n微服务是继SOA后，最流行的服务架构风格之一。\n\n按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。\n\n微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。\n\n遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反－－降低项目的开发效率，这是本书的创作初衷之一。\n\n在国内外的技术社区中，比较推崇现有开源方案，如\"Spring Cloud全家桶\"或者阿里开源的\"Dubbo\"。\n\n上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断，等微服务架构所必须的的核心功能。\n\n使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的动力。\n\n为什么需要服务发现，又如何实现它呢？配置中心呢....思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二。\n\n已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。\n\n为此，我撰写了这本《从0到1实战微服务架构》。让我们\"暂时忘掉\"已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。\n\n我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案。\n\n如果本书帮助了你，欢迎在在[github](https://github.com/liheyuan/hands-on-microservices)加Star，但严禁用于商业用途！(参见本页底部版权声明)\n\n由于能力水平所限，本书难免存在各种错误，恳请各位进行指正(Issue or PR)，谢谢！\n\n## 读者基础\n\n由于篇幅、精力所限，本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：\n\n* Git\n* Maven & Gradle\n* Docker & Kubernetes\n* Java\n* Spring / Spring Boot \n* 数据库: 如MySQL\n* 消息队列: 如RabbitMQ\n* 缓存系统: 如Memcached \n* 内存数据库: 如Redis\n\n本书可以供架构师、项目经理、高级服务端程序员参考、学习。\n\n动手实战是本书的核心内容，因此本书所涉及的全部代码，都托管到了我的[Github上](https://github.com/liheyuan)(以lmsia-开头的项目)。\n\n这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。\n\n## 版权\n\n本书虽然在github上公开写作，但版权归本人[Coder4](https://coder4.com)所有。\n\n依照 [署名-非商业性使用-相同方式共享](https://creativecommons.org/licenses/by-nc-sa/2.5/cn/) ，任何人可以在保留署名的情况下转载。但严禁用于商业用途。\n\nThis is a book powered by [mdBook](https://github.com/rust-lang/mdBook).\n"
},
{
"path": "src/SUMMARY.md",
"content": "# [从0到1实战微服务架构](./README.md)\n\n- [前言](./README.md)\n\n- [微服务概述](./ch01-architecture/micro-service-intro.md)\n \n - [微服务研发工具链](./ch01-architecture/rd-ops-toolchain.md)\n - [持续集成、持续部署、持续交付](./ch01-architecture/continuous-x.md)\n - [一种微服务的分层架构](./ch01-architecture/ms-architecture.md)\n - [一种微服务分层架构的技术栈选型](./ch01-architecture/ms-tech-stack.md)\n\n- [微服务开发上篇](./ch02-ms-dev1/README.md)\n \n - [Gradle构建工具配置](./ch02-ms-dev1/gradle.md)\n - [Sprint Boot项目与Gradle的集成](./ch02-ms-dev1/spring-boot.md)\n - [Spring Boot集成SQL数据库1](./ch02-ms-dev1/database1.md)\n - [Spring Boot集成SQL数据库2](./ch02-ms-dev1/database2.md)\n - [Spring Boot集成gRPC框架](./ch02-ms-dev1/rpc.md)\n - [Spring Boot集成Redis](./ch02-ms-dev1/redis.md)\n\n- [微服务开发中篇](./ch03-ms-dev2/README.md)\n \n - [Nacos注册中心：注册篇](./ch03-ms-dev2/registry1.md)\n - [Nacos注册中心：发现篇](./ch03-ms-dev2/registry2.md)\n - [Spring Boot集成配置中心](./ch03-ms-dev2/config.md)\n - [Spring Boot集成熔断、限流、降级](./ch03-ms-dev2/circuit-breaker-and-limiter.md)\n - [Spring Boot集成消息队列](./ch03-ms-dev2/mq.md)\n\n- [微服务开发下篇](./ch04-ms-dev3/README.md)\n \n - [基于ELKFK打造日志平台](./ch04-ms-dev3/elkfk.md)\n - [基于SkyWalking的链路追踪系统](./ch04-ms-dev3/skywalking.md)\n - [基于MicroMeter实现自定义应用监控指标](./ch04-ms-dev3/micrometer.md)\n - [基于VictoriaMetrics + Grafana的监控系统](./ch04-ms-dev3/victorialmetrics.md) \n\n- [容器与编排系统](./ch05-k8s/README.md)\n \n - [从集装箱到容器](./ch05-k8s/container.md)\n - [快速入门Kubernetes](./ch05-k8s/k8s-101.md)\n - [搭建Kubernetes集群](./ch05-k8s/k8s-cluster.md)\n - [搭建Kubernetes高可用集群](./ch05-k8s/k8s-ha-cluster.md)\n - [通过ingress暴露内部服务](./ch05-k8s/k8s-ingress.md)\n\n- [持续交付流水线](./ch06-cd/README.md)\n \n - [Jenkins搭建入门](./ch06-cd/jenkins.md)\n \n - [Jenkins定制Agent](./ch06-cd/jenkins-custom.md)\n \n - [Jenkins实现Kubernetes部署流水](./ch06-cd/jenkins-k8s.md)\n \n - [Jenkins优化Kubernetes部署流水线](./ch06-cd/jenkins-k8s-optimize.md)\n\n- [工具链](./ch07-tools/README.md)\n \n - [基于LDAP的内网统一认证](./ch06-cd/jenkins.md)\n - [JFrog Artifactory搭建Maven私有仓库](./ch07-tools/ldap.md)\n - [使用Registry2搭建Docker私有仓库](./ch07-tools/registry2.md)\n"
},
{
"path": "src/ch01-architecture/README.md",
"content": "# 第1章 微服务架构概述\n\n当我们讨论服务端的架构时，“微服务”已经成为了最热门的关键字。\n\n如果没有接触过\"微服务\"，那么你的心里一定存在很多号？\n\n不要急，我们将从三个基本问题谈起：\n\n- 什么是“微”服务?\n\n- 为什么需要微服务?\n\n- 微服务是“银弹”么？\n\n接着，我们将沿着：\n\n- 研发工具链\n\n- 微服务架构\n\n两个线索展开，最后将讨论技术选型。\n\n让我们开始“微”服务的探索之旅吧:-)\n"
},
{
"path": "src/ch01-architecture/continuous-x.md",
"content": "# 持续集成、持续部署、持续交付\n\n标题里的三个“持续”在前几年特别火热，属于技术热词(BuzzWord)。\n\n持续交付(Continuous Delivery)由马丁·福勒（Martin Fowler）于2006年提出。\n\n是的，你没看错，又是马丁·福勒，那位提出微服务的大神。\n\n歪个楼，介绍一些马丁·福勒的代表作：\n\n- 《重构：改善既有代码的设计》\n\n- 《企业应用架构模式》\n\n- 《敏捷软件开发宣言》(联合)\n\n- “微服务”、“持续部署” ....\n\n以上任何一条单独拿出来，都足以封神。\n\n言归正传，我们在一本“微服务”的书中讨论持续交付，仅仅因为它是由大神提出的么？\n\n当然不是，我们将在本文的末尾再讨论这个问题。\n\n[这篇](https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/)文章很好的阐述了三个概念的联系与区别，我们展开讨论。\n\n## 持续集成\n\n小王每次向gitlab提交一个代码，就会触发一次项目的自动构建、运行单元测试，这就是持续集成(Continuous Integration)。如下图所示：\n\n\n\n假设小王在提交中引入了一个Bug，借助CI流程(中的集成 or 单元测试)，我们就能在第一时间发现，并尽早修复问题。\n\n管理学大师戴明指出：“问题发现的越早，修复的成本越低”。通过持续集成，我们可以尽早发现问题，从而降低(修复问题带来的)返工成本。\n\n## 持续部署\n\n持续部署(Continuous Deployment)指的是：在持续集成(成功)的基础上，自动将服务部署到\"类似于线上\"的环境中，如下图所示：\n\n\n\n为什么要部署到\"类似于线上环境\"呢？因为代码只在\"集成阶段\"通过了一部分\"单元测试\"，假设单元测试覆盖不全，甚至还需要人工测试，那就可能将隐含的Bug发布到线上，造成生产事故。\n\n图中画的\"TEST\"(测试环境)、\"STAGING\"(预发环境)，都是这类\"类似线上环境\"。当新版本通过最终确认后，再手动(MANUAL)部署到线上。\n\n## 持续交付\n\n持续交付(Continuous Delivery)在持续部署的基础上，更近了一步：成功发布到\"类似生产环境\"后，会继续自动发布到线上，如下图所示：\n\n\n\n显然，这种\"自动发布\"需要极强的自信和勇气。这可能源于充分的单元测试，清晰的架构，以及对业务能力的自信。\n\n实际上业界只有极少数公司\"从容地\"实现了上述意义上的\"持续交付\"。\n\n其余宣称实现了\"持续交付\"的公司，或者混淆了持续部署的概念，或者对技术故障存在较大容忍度。 (先发布再灰度，难道不是一种容忍?)\n\n这并不是高级黑，如果你认真做过一段时间软件开发，应该能明白“即使100%的单测覆盖率，也不能自动检查出尚未发现的Bug”，更何况绝大多数项目根本无法达到100%单元覆盖率。\n\n我们回到本文开头的问题：为什么要在一本“微服务”的书中，讨论持续部署？\n\n还记得微[服务概述](./micro-service-intro.md)一节中，微服务的缺点么？可靠性陷阱、运维复杂度升高。\n\n- 借助持续集成，能够尽早发现缺陷，提升微服务架构下的可靠性。\n\n- 应用持续部署，可以上线效率，降低运维难度。\n\n由此可见，持续集成、持续部署，能够切实解决微服务中存在的问题。我们将在本书的后续章节，打造自己的持续集成系统，敬请期待。\n"
},
{
"path": "src/ch01-architecture/micro-service-intro.md",
"content": "# 微服务概述\n\n## 什么是“微”服务？\n\n如果你仔细观察，会发现我在上一行的标题中，将“微”打了个引号。\n\n如果我们暂时去掉这个''微\"字理解，微服务就是我们熟知的“服务端” 或者 “后端”。\n\n现在让我们把微字加回来:-)\n\n\"微服务\"(Microservices)由马丁·福勒（Martin Fowler）提出的一种架构理念，[原文]([Microservices](https://martinfowler.com/articles/microservices.html))发表于2014年。\n\n> 微服务是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。\n\n我们抓三个关键点来理解：\n\n- 单一应用划分为一组更小的服务：将一个较大的、复杂的应用，拆分为多个小的服务。你可能会问：“这样不会增加复杂度么”？是的，会增加。但这种拆分也会带来明显的优点，我们后面会提到。\n\n- 独立的进程：每个微服务独立运行在自己的进程中，互不干扰。虽然这里并没有限制进程的部署方式，但可以想见，经过\"划分\"后的微服务，势必会产生众多进程。微服务是拆分而来的，他们之间势必存在逻辑的耦合。由此，会产生新的问题\"微服务间的通信\"。\n\n- 相互协调、配合：微服务的进程间需要通信、交互。从理论而言，所有IPC(Inter-Process Communacation，进程间通信)的方式都可以完成这个过程。但微服务的进程众多，很难完整地部署在同一台机器上，这势必产生跨主机的网络通信。所以，在微服务中，多采用RPC(Reomote Procedure Call，远程过程调用)的方式来完成通信。\n\n\n\n上图展示了单体服务 和 微服务的区别。\n\n## 为什么需要微服务？\n\n在前文中，我们挖了一个坑：'微服务的划分会导致复杂度上升'，为什么还要使用一项有缺陷的技术呢？\n\n我们先讲第一个故事。\n\n小张入职了一家互联网创业公司，一开始只有3个后端程序员，每天的工作是：和产品经理讨(si)论(bi)需求、写代(b)码(ug)，改Bug，工作紧张但规律。服务端的上线窗口是周五下午：合并分支、代码Review、推送线上，一气呵成，不仅能准点下班，还能去吃个火锅。\n\n过了两个月，行业赶上了风口，公司的业务快速发展，后端团队也快速膨胀到20人。然而，麻烦也接踵而至：大家修改的是同一个仓库下的服务端代码，\"解冲突\"成为了家常便饭，还发生了几次\"一个小修改，破坏了其他业务主流程“的严重线上事故。\n\n为了改善这种情况，老板招聘了2位QA(质量保证，测试)人员，由他们负责测试工作。然而，一个很小的改动都需要对整个后端服务的case进行全量回归测试。一个功能的开发需要1天，测试却耗费1周，迫于老板的压力，研发同学只能安慰自己：XX功能简单，不需要测试了，直接上线。\n\n最终，周五成为了\"噩梦日\"：周四晚上要提前开一个Excel表、统计好第二天要上线的需求，并按优先级排定顺序。周五全员提前1小时来公司，开始逐个逐个需求的\"合并代码\"”、\"解冲突\"，“上线”、\"观察\" 、“回滚”、“修改代码”...... \n\n上线结束的收工时间从6点变成了9点，又逐渐拖到了11点，最后索性全员加班、通宵上线。技术团队的每一位同学，都感到身心俱疲。\n\n听完这个故事，你是否有\"似曾相识\"的感觉？\n\n科普一下，上述故事中的服务一般称作“单体服务” 或者 “巨石服务”(Monoliths)。\n\n接下来，是第二个故事。\n\n由于工作强度大、线上故障频发、团队士气低落，老板请来了老刘担任技术经理。\n\n第一周：老刘带领团队将复杂、臃肿的\"巨型服务\"拆分成了“用户”、“订单”、“服务”三个微服务。\n\n第二周：老刘将团队进行了上述类似的拆分，也分成了三个小组。\n\n第三周：事情有了微妙的变化。分组后，合并代码引发的冲突减少了。开发业务时，多数的改动都封闭在单独的微服务内，改动造成的影响范围减少了，测试周期缩短了。\n\n......\n\n三个月后的一个周五的下午，（得益于提高的交付质量，以及微服务的独立并行上线），团队提前2小时完成了上线，距离上一次故障通报已经过去了两个月。\n\n研发讨论群里，小张发了一条消息：“今天居然可以正点下班了，老刘真厉害！”\n\n老刘回复：这是大家的努力的结果，真正“厉害”的应该是“微服务”。\n\n听完这两个故事，我们来总结下微服务架构的两个优点：）\n\n- 逻辑清晰：一个微服务只负责一项(或少数几项)很明确的业务，逻辑更加简介清晰，易于理解。\n\n- 独立自治：每个微服务由一个小组负责。减少了跨团队的代码冲突，同时降低了改动的影响范围，提高了研发效率。\n\n在故事之外，微服务架构还具有以下的优点：\n\n- 伸缩性强：相对于庞大的巨石服务，微服务更加独立，可以针对不同的性能需求，有选择的对不同微服务进行伸缩。举个栗子：明天有大促，产品预测：注册功能提升10倍，其他功能无波动。针对巨石服务，我们只能整体扩容10倍；微服务架构下，我们只需要10倍扩容用户微服务。\n\n- 技术异构性：每个微服务内可以使用不同的技术栈，甚至不同的开发语言。只要微服务之间使用统一的通信方式即可。\n\n微服务架构有很多优势，那团队抓紧上马微服务吧？\n\n## 微服务是“银弹”么？\n\n直接泼一盆冷水：\n\n> There is no Silver Bullet. -- 《人月神话》\n\n微服务不是“银弹”，它存在以下缺点：\n\n- 复杂度升高：在巨石服务中，所有修改都集中在同一个项目内；在微服务架构下，复杂功能的开发，需要同步修改多个微服务，复杂度骤然升高。\n\n- 性能损耗：原本在巨石服务中的方法调用，演变为微服务之间的跨进程、网络通信。性能会受到较大影响。\n\n- 可靠性陷阱：假设每个服务的可靠性都是99%，一个巨石服务，可靠性是99%、三个微服务的可靠性会下降到99% x 99% x 99% = 97%。\n\n- 运维难度加大：巨石服务被拆分成N个微服务，部署的数量翻倍的增长。此外，多组微服务的运行，也会增大运维、监控的难度。\n\n有意思的是：\"拆分\"带来了优点，也引入了缺点。\n\n> 夫尺有所短，寸有所长，物有所不足，智有所不明。 -- 《楚辞．屈原．卜居》\n\n微服务架构也是如此，它的优缺点并存。\n\n## 微服务适用什么场景？\n\n什么场景适用微服务，什么场景不适用呢？\n\n这篇文章[《When to use and not use microservices》]([Best of 2020: When To Use - and Not To Use - Microservices - Container Journal](https://containerjournal.com/topics/container-ecosystems/when-to-use-and-not-to-use-microservices/))给出了一些建议：\n\n适用微服务架构的场景：\n\n- 希望巨石服务能适应“可扩展性”、“敏捷性”、“可管理性”，提升交付速度时\n\n- 需要为(使用陈旧技术开发的)的老系统，迭代新功能时\n\n- 有一些相对独立的模块可以跨业务复用时：如登录、检索、身份验证等。\n\n- 构建需要快速交付、创新度高、敏捷的应用 / 服务\n\n不适用微服务架构的场景：\n\n- 业务简单，无需处理复杂问题\n\n- 团队规模太小，尚无法负担微服务拆分带来的复杂度提升\n\n- 为了微服务而微服务\n\n最后，引用马丁·福勒（Martin Fowler）论文的结尾做结束本节的讨论。\n\n> 我们怀着谨慎、乐观的态度写了这篇文章。到目前为止，我们已经看到：微服务风格是一条非常值得探索的路。我们不能肯定地说，我们将在哪里结束，但软件开发的挑战之一是，你只能基于目前能拿到手的、不完善的信息作出决定。\n"
},
{
"path": "src/ch01-architecture/ms-arch.plantuml",
"content": "@startuml\n\ntitle \"微服务架构实现\"\n\npackage \"聚合接入层\" as l5 {\n [聚合服务1] as n51\n [聚合服务2] as n52\n [聚合服务3] as n53\n [PaddingPadding] as n54\n hide n54\n\n [n51] -[hidden]right-> [n52]\n [n52] -[hidden]right-> [n53]\n [n53] -[hidden]right-> [n54]\n}\n\npackage \"业务服务层\" as l4 {\n [微服务1 ] as n41\n [微服务2] as n42\n [微服务3] as n43\n [微服务4] as n44\n [Pa] as n45\n hide n45\n\n [n41] -[hidden]right-> [n42] \n [n42] -[hidden]right-> [n43]\n [n43] -[hidden]right-> [n44]\n [n44] -[hidden]right-> [n45]\n}\n\npackage \"微服务设施层\" as l3 {\n [开发框架] as n31\n [RPC] as n32\n [服务注册发现] as n33\n [配置中心] as n34\n [ ] as n35\n hide n35\n \n\n [熔断/限流] as n36\n [数据库] as n37\n [NoSQL] as n38\n [消息队列] as n39\n\n [链路追踪] as n3a\n [监控] as n3b\n [报警] as n3c\n [日志] as n3d\n\n\n [n31] -[hidden]right-> [n32]\n [n32] -[hidden]right-> [n33]\n [n33] -[hidden]right-> [n34]\n [n34] -[hidden]right-> [n35]\n\n [n31] -[hidden]down-> [n36]\n\n [n36] -[hidden]right-> [n37]\n [n37] -[hidden]right-> [n38]\n [n38] -[hidden]right-> [n39]\n\n\n [n36] -[hidden]down-> [n3a]\n\n [n3a] -[hidden]right-> [n3b]\n [n3b] -[hidden]right-> [n3c]\n [n3c] -[hidden]right-> [n3d]\n}\n\n\npackage \"运维平台层\" as l2 {\n [CI/CD系统] as n21\n [部署版本系统] as n22\n [容器调度系统] as n23\n [PaddingP] as n24\n \n hide n24\n\n n21 -[hidden]right-> n22 \n n22 -[hidden]right-> n23\n n23 -[hidden]right-> n24\n}\n\n\n\npackage \"基础设施\" as l1 {\n [计 算 资 源] as n11\n [存 储 资 源] as n12\n [网 络 资 源] as n13\n [PaddingPPddi] as n14\n\n hide n14\n\n n11 -[hidden]right-> n12\n n12 -[hidden]right-> n13\n n13 -[hidden]right-> n14\n}\n\nn51 -[hidden]down-> n41 \nn41 -[hidden]down-> n31\nn3a -[hidden]down-> n21\nn21 -[hidden]down-> n11 \n\n\n@enduml"
},
{
"path": "src/ch01-architecture/ms-architecture.md",
"content": "# 一种微服务的分层架构\n\n在上一小节，我们讨论了微服务架构“的的特征、优缺点等话题。\n\n你可能对微服务有了一个模糊的概念，依然感觉不够清晰。\n\n这种感受能够理解。因为，微服务的理论只是提供了一种“架构风格”的建议，并不包含具体的实施方案。\n\n下图展示了一种微服务的分层架构：\n\n![微服务整体架构](./ms-arch.png \"微服务整体架构\")\n\n让我们自底向上、逐层分解：\n\n1. 基础设施层\n \n 基础设施层涵盖了服务端运行时，所需要的物理资源。包括：计算资源、存储资源、网络资源等。\n \n 针对小型公司，可以直接选用云计算平台的资源(如阿里云、AWS等)；中大型公司出于成本、审计等因素，会自建机房或混合云。\n \n 计算资源：CPU、GPU、内存等。除了CPU的核数、内存容量，配比等常见问题，还需要考虑计算资源的弹性伸缩能力，即如何应对“平台大促”等场景带来的流量提升。\n \n 存储资源：不仅要考虑磁盘容量，还要考虑磁盘性能([IOPS]([IOPS - 维基百科，自由的百科全书](https://zh.wikipedia.org/wiki/IOPS)))。举个例子：服务端日志主要是顺序写，异步处理 + 大容量机械磁盘就能满足要求；对MySQL等数据库场景，涉及大量随机读，使用SSD可以显著提升性能。\n \n 网络资源：外网带宽(峰值)、内网带宽、负载均衡、VPC等。内外网带宽问题较为常见，我们不再讨论。负载均衡：当业务流量规模升高后，接入层的传统软负载解决方案(Nginx、LVS)会显得力不从心。硬件负载均衡(F5)可以提供更高的性能，但做为专用计算的商业产品，其价格在百万以上。这几年，随着Kernel By Pass技术的兴起，基于X86通用硬件 + Linux的的软负载均衡也取得一定的性能突破，感兴趣的话，可以参考这篇[文章]([从Maglev到Vortex，揭秘100G＋线速负载均衡的设计与实现-InfoQ](https://www.infoq.cn/article/Maglev-Vortex/))。\n \n 基础设施层的技能栈主要是：运维、网络建设，我们不在本书中做更多讨论。\n\n2. 运维平台层\n \n 运维平台层是“[持续交付](continuous-x.md)”的重要载体，包括：\n \n 持续部署系统：构建从代码仓库、持续集成、持续部署的全链路系统、最终实现持续交付。\n \n 部署的版本管理系统：管理部署镜像粒度的版本，以支持滚动发布、回滚等部署功能。\n \n 容器、容器管理调度平台：容器是一种操作系统级的轻量虚拟化技术。在部署系统中，不仅需要容器技术、还需要容器调度管理系统。这两项技术我们会在后续章节展开讨论。\n\n3. 微服务设施层\n \n 本层为微服务的开发和运行提供公用的设施基础。\n \n 在这里我们只做基本介绍，在后续章节会详细展开。\n \n 开发框架：微服务的开发需要一些基础的编程框架，可以自己从零搭建，也可以基于成熟开源框架完善。\n \n RPC：微服务内部使用RPC(Remote Procedure Call)完成通信。\n \n 服务注册与发现：微服务A调用服务B且后者有3个实例，如何感知这3个实例的IP、端口，以及A要调用哪个实例呢？这就是服务的注册与发现问题，是微服务的核心问题之一。\n \n 配置中心：微服务的数量、实例众多，逐一修改配置文件的传统模式，既不经济又容易出错。配置中心是一个中央(但不一定是单机)配置系统，负责配置管理、修改等工作。\n \n 熔断：当微服务调链路上，服务不可用或响应时间太长时，触发熔断，快速提前返回。举个例子：家里有用电设备路时电流过大，空气开关会直接跳闸，防止造成进一步的破坏。\n \n 限流：为了保护服务不被流量击垮，而提前限制流量。举个例子：经过测算，故宫接待能力是每日1万人。那么当天超过1万后，就触发限流，不让更多游客入园。\n \n 数据库：传统的SQL数据库用于业务数据落盘，NoSQL数据库则用于缓存或高性能存取。\n \n 消息队列：将业务流量“削峰填谷”，对应对突发流量。\n \n 中间件：中间件是介于 服务端 与 数据库、消息队列等设施的中间。中间件帮助 业务服务更简单地使用这些基础设施。\n \n 近几年，“可观测性”成为了新的技术热词。这个舶来于控制理论的词，在软件系统中指的是：可以帮团队有效调试系统的工具或解决方案。以这个视角看，下述部分都是可观测性的一部分：\n \n 日志：如何在众多的微服务实例中，快速定位到某一种出错日志？日志平台实现了微服务实例中的日志收集、存储、检索、分析。\n \n 监控系统：通过采集多种指标，实时反馈系统运行状态，保证服务的平稳运行。举个生活中的例子：汽车驾驶位的仪表盘。\n \n 报警系统：当监控系统发现异常时，及时将报警发送出来。\n \n 链路追踪：当服务A->B->C调用链上发生超时，如何快速定位哪个环节发生了故障？链路追踪解决了分布式、复杂调用链路中的采集、追踪，分析工作。\n\n4. 业务服务层\n \n 借助“基础设施“、”运维平台“、”微服务设施“的帮助，我们可以更高效、稳健的应用微服务，实现业务目标。关于微服务的拆分、建模理论，可以参考“领域驱动设计”的相关内容，本书不做讨论。\n\n5. 聚合接入层\n \n 在“[微服务概述](micro-service-intro.md)”一节中，我们曾提到微服务的缺点之一：拆分导致的复杂度升高。在当前主流的前后端分离架构中，用户对这一拆分基本无感知。复杂度被转嫁到 前端 / 客户端 中：原本只需要调用一个接口，现在要分别调用N个微服务。还需要考虑时序关系、错误处理等。聚合接入层就是为解决这个问题而生的，他聚合多个微服务的调用，只保留必要字段，为前端 / 客户端提供了统一、清晰的服务接口。聚合接入层可以由服务端实现，有时还会加入部分熔断、限流等逻辑，组合成为微服务网关。聚合接入也可以由前端实现，有时也被称作BFF(Backend For Frontend)。\n\n在剖析微服务的各层架构之后，不难发现：微服务的架构下，需要多个团队，多层系统、多纬度的支持。这也印证了在“[微服务概述](micro-service-intro.md)”一节中的观点：应用微服务架构，需要较高成本。\n\n因此，尽量选用成熟、易维护的技术，从而尽可能降低成本，显得尤为重要。我们将在下一节展开讨论技术选型。\n"
},
{
"path": "src/ch01-architecture/ms-tech-stack.md",
"content": "# 一种微服务分层架构的技术栈选型\n\n我们在[工具链](./rd-ops-toolchain.md)、[一种微服务的分层架构](./ms-architecture.md) 两小节中讨论了技术栈的需求。\n\n在本节中，我们将具体讨论技术栈的选型。\n\n你可能注意到，上一节的标题是“一种微服务的分层架构”，而这一节的标题是“一种微服务分层架构的技术栈选型”。\n\n加上“一种”这个词是有意而为之，请不要怀疑我的语文水平:-)\n\n\"一种\"强调的是：\n\n- 微服务只是一种架构风格，他可以有N种不同的实现，上一节只介绍了其中一种。\n\n- 每一种微服务架构的实现，也可以对应N种不同的技术栈选型。\n\n那么，在这N^2种架构 + 技术栈的组合种，哪一种才是最好的？\n\n不急着回答，我们先来看下这个：\n\n> php is the best language for web programming.\n\n这是PHP官方手册的原文，更多人更熟悉前5个单词，“PHP是全世界最好的语言”。\n\n但加上后3个单词“for web programming”后，就变成了“PHP是web领域最好的语言”。\n\n而我的观点(哪个架构更优) 与 PHP社区(关于语言优劣)的观点，是一致的：没有最好的语言(技术)，只有最适合具体场景的。\n\n因此，我们只会针对各项场景，列出技术选型，而不会打“为什么A比B好的”口水战。\n\n## 容器管理平台的技术选型\n\n微服务架构下会对服务进行拆分，产生大量的服务实例。\n\n容器化技术，可以实现环境隔离、快速部署，是微服务架构的基石。\n\nDocker凭借“快速”、“可移植性”等特性\"\"一战成名\"，是单机或小规模应用部署的最佳选择\n\n然而，在复杂的分布式部署场景中，\"扩容\"、\"编排\"、\"故障恢复\"等成为了\"刚需\"，“容器管理平台”应运而生。在这个赛道上，曾经出现过三个主流产品：\n\n- swarm: Docker公司于2014年末推出的容器集群技术方案。尽管swarm是Docker公司的“亲儿子”、手握大量社区资源，但很快被Kubernetes超越。\n\n- Kubernetes: 简称k8s，支持自动部署，扩展和管理容器化应用程序的开源系统。k8s借鉴了Google的Borg管理系统，自问世以来发展迅猛，当前已经成为了容器管理的事实标准。\n\n- Marathon: 构建在[Apache Mesos]([Apache Mesos](http://mesos.apache.org/))集群上的一套容器集群管理软件。由于Mesos的部署存在门槛，Marathon项目的关注度并不高，社区也并不活跃。其上一个发布版本依然停留在2019年，已经近2年没有更新。\n\n因此，我们\"毫无争议\"地选择k8s作为微服务架构下的容器管理平台。\n\n除了容器管理平台，我们还需要镜像仓库存储应用的容器镜像，我们将使用Docker搭建私有镜像仓库。\n\n## 微服务设施层的技术选型\n\n设施层涉及较多的技术需求，技术选型如下：\n\n| 需求 | 选型 | 版本 |\n| ---------------- | ------------------------- | -------------- |\n| 开发语言 | Java | 8 |\n| 开发框架 | Spring Boot | 2.5.4 |\n| RPC | gRPC | 1.14.x |\n| 服务注册 / 发现 / 配置中心 | Nacos | 2.x |\n| 熔断 / 限流 | Resilience4j | 1.7.1 |\n| SQL数据库 | MySQL | 8.0.X |\n| 内存数据库 | Redis | 6.2 |\n| 消息队列 | RocketMQ | 4.9.1 |\n| 日志 | Kafka + ELK | 2.13 + 7.14.X |\n| 监控 / 告警 | VictoriaMetrics + Grafana | 1.64.1 + 8.1.X |\n| 链路追踪 | SkyWalking | 8.7.0 |\n\n开发语言：我们选择了Java做为开发语言。与新近崛起的Go、Rust等语言相比，Java不是最完美的语言，但它依然拥有较高的开发、运行效率，最充足的人才供给。版本方面我们选择Java 8（最后一个免费的Java版本）。\n\n开发框架：在Java开发领域，Spring生态的渗透率已超过60% ([出处]([Spring dominates the Java ecosystem with 60% using it for their main applications | Snyk](https://snyk.io/blog/spring-dominates-the-java-ecosystem-with-60-using-it-for-their-main-applications/)))。顺应这一趋势，我们选择Spring 生态内的Spring Boot做为主要开发框架。Spring Boot提供的注解配置、嵌入式容器、starter等特性，可以极大简化Java应用的开发。\n\nRPC框架：我们选择开源的gRPC做为RPC框架，它使用Protocl Buffer序列化，HTTP 2传输协议，具有更灵活的通信模式和较高的传输效率。\n\n服务注册、发现、配置中心：[Nacos]([什么是 Nacos](https://nacos.io/zh-cn/docs/what-is-nacos.html))是阿里巴巴开源的服务管理项目，同时具备服务注册、发现、配置中心。Nacos原生支持Spring Boot、k8s等融合方向。经过几年的发展，Nacos已经较为成熟，支撑了阿里巴巴、中国移动等数十家大型公司的线上系统。\n\n熔断、限流：本书不会探讨Service Mesh等平台级别的流量控制方案。我们主要讨论服务进程级别的熔断、限流方案。老牌项目Hystrix停更后，我们选择开源的Resilience4j做为熔断、限流的Java库解决方案。\n\n数据库：做为开源数据库的佼佼者，MySQL常年稳居市场份额的前三名。我们选择其较新的稳定版8.0.X。\n\n内存数据库：做为SQL数据库的补充，内存数据库的应用场景是：吞吐量更大、延迟更低。高性能的Redis是最佳选择。根据[官方评测](https://redis.io/topics/benchmarks)，Redis 6.x在开启pipeline模式的前提下，可以提供高达55万RPS。\n\n消息队列：Apache RocketMQ是阿里巴巴的开源的分布式消息队列，具有极低的延迟和较高的吞吐量。相比于老牌的Kafka，Rocket MQ更适用于消息队列的场景。我们选用其最新稳定版4.9.1。\n\n日志：ELK是经典的日志日志方案。在此基础上，我们前置增加了Kafka，利用其强大的写能力，构建起缓冲队列，以应对海量日志的突发写入。\n\n监控 / 告警：纵观DevOps领域，Prometheus + Grafana已经成为了监控领域的事实标准。然而，Prometheus并不支持原生的集群部署，其在大规模应用下很容易出现瓶颈。[VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics)是一款可以嵌入Prometheus的分布式时序存储引擎。起初VictoriaMetrics只想做一个引擎，在近几个版本社区加大了对vmagent的开发投入。vmagent是一款轻量级的代理，兼容Prometheus协议，可以直接替代Prometheus完成大部分工作。在本书中，我们直接选择VictoriaMetrics + Grafana做为兼容告警的默认技术栈。\n\n链路追踪：[SkyWalking](https://skywalking.apache.org/)是由国人主导的一款开源APM(application performance management)。在小米、滴滴等公司都有应用。我们选择其最新的稳定版本。\n\n看了上面的文字，你可能有点困惑：“只是简单罗列选型结果，并没有具体分析过程“？\n\n技术选型是一个非常大的话题，每一个点单独拎出来，都能洋洋洒洒的写一章出来，但是我觉得必要性不大，原因在于：\n\n- 技术演进的速度非常快，今天适合的明天就有可能被淘汰(看看Docker)\n\n- 每个公司面临的具体场景情况都是不同的，很难穷尽、更无法全部都满足\n\n因此，我只是在自己可见的技术水平内，选择了相对靠谱的方案，解决了一部分“选择障碍的问题”，如果你有更优秀的选择，也欢迎提Issue交流、讨论。\n"
},
{
"path": "src/ch01-architecture/rd-ops-toolchain.md",
"content": "## 微服务研发工具链\n\n> 子曰：“工欲善其事，必先利其器。居是邦也，事其大夫之贤者，友其士之仁者。” \n> \n> -- 《论语》\n\n普通话版：工匠想要做好工作，先要把工具打磨锋利。\n\n程序员版：软件工程师要想写好代码，需要一把机械键盘，并定期清洗轴以维持最佳手感。\n\n对于程序员而言，除了键盘等硬件，还有一系列软件。我们这里将这些软件称为工具链。\n\n## 小王的一天\n\n下面，让我们跟随小张 - 是的，就是在风口创业公司的那位 - 看看在微服务架构下，研发工具链包含了哪些内容。\n\n| 时间 | 工作 | 工具需求 | 备注 |\n| ----- | ------------------------------ | ------------------------------ | ---------------------- |\n| 09:01 | 打开浏览器，登录公司内网 | 使用同一个账号，登录公司所有的内部系统。 | 暂不讨论“操作系统”、“浏览器”等通用软件。 |\n| 09:03 | 打开代码审核平台，查看Review | 代码版本控制、代码托管，代码审核 | |\n| 10:23 | 老张让我升级下xx的包，加了新接口 | 版本依赖管理系统 | 我们将开发语言暂时限定为Java |\n| 11:56 | 修改了一部分逻辑，午饭前抓紧提交上去，看能否跑通所有Case | 持续集成(Continuous integration)系统 | 暂不讨论“IDE”等通用软件。 |\n| 15:20 | 功能开发完毕，上线！ | 持续交付(Continuous delivery)系统 | |\n| 16:03 | X功能重构，拆分到两个微服务中 | 微服务开发辅助工具 | |\n\n## 研发工具链\n\n小张的公司还处于创业阶段，出于节省成本的考虑，我们尽量选择开(mian)源(fei)的解决方案：\n\n1. 内部帐号统一管理：在企业的内部，存在许多内部系统。出于安全性、管理性的考虑，需要统一的帐号管理系统。这里我们选用[OpenLDAP](https://www.openldap.org/)：一款的开源的帐号管理服务，它实现了广泛使用的“轻量级目录管理协议”(LDAP v3)，可以轻松对接各类系统的帐号管理功能。\n\n2. 代码管理：团队协作的软件开发模式，需要版本控制系统。我们选用了[Git](https://git-scm.com/)做为代码的版本控制系统。在代码的托管、审核方面，[Gerrit](https://www.gerritcodereview.com/)和[GitLab](https://about.gitlab.com/install/?version=ce)都是成熟的开源解决方案。Gitlab上手容易，生态链更加成熟；Gerrit有一定上手门槛，在代码Review方面更加优秀。关于两者的讨论，可以参考这篇[帖子](https://www.reddit.com/r/git/comments/8ekeem/do_you_use_gerrit_software/)。经过多方面的综合考虑，我们选择了GitLab。\n\n3. 版本依赖系统：在Java开发中，[Maven](https://maven.apache.org/)是依赖管理的事实标准。同时在企业开发中，不希望将私有包发布到公开仓库中，我们选用[Nexus Repository OSS](https://www.sonatype.com/products/repository-oss)搭建私有的Maven仓库。\n\n4. 持续集成、持续交付，持续部署是三个既相近又重要的概念，我们将在下一小节展开讨论。\n\n5. 微服务辅助开发工具：在微服务架构下，新增微服务、升级pom版本，接口变更等操作会频繁发生。需要开发一些辅助工具，提升研发效率。我们会在后面展开讨论。\n\n针对上述选择的工具，我们会在后续章节详细介绍。\n\n## 微服务辅助开发工具\n\n结合微服务的开发特点，我们需要这样一些辅助工具：\n\n- 自动创建新的微服务：包括从模板项目生成微服务代码、自动创建git项目、部署项目\n\n- RPC桩文件生成：在RPC的(IDL)接口文件变更后，需要重新生成桩文件，这个步骤较为繁琐，需要工具辅助完成。\n\n- pom版本自动升级：微服务之间的版本依赖，更新会更加频繁，我们需要一个工具，自动修改pom版本\n\n这里我们只初步讨论一下需求，具体的实现会在后续章节展开。\n"
},
{
"path": "src/ch02-ms-dev1/README.md",
"content": "# 微服务开发上篇：开发框架及其与RPC、数据库、Redis的集成\n\n从这一章开始，我们正式进入微服务开发篇，共分上、中、下三篇。\n\n本章我们将讨论开发框架，框架与RPC、数据库、Redis的集成。\n\n2001年，我刚开始编程时，接触的第一个语言是\"ASP\"(没有.net)，它通过脚本注解的方式，实现动态功能(存取数据库等)，有点类似于PHP。在那个没有开发框架的年代，我们依然可以实现功能。但是这里只是“功能上的满足”，确无法做到“工程上的最优”，例如：\n\n- HTML与脚本混编，无论是页面样式修改，还是逻辑修改都很麻烦（视图、逻辑混合）\n\n- 有不少功能重复的代码，无法复用（如创建数据库连接）\n\n- 页面之间的内部依赖难以处理（往往只能通过url / session参数传递）\n\n开发框架的出现，解决了上述部分问题，以Spring为例：\n\n- Spring MVC实现的分层架构，将页面、视图、逻辑层强制分离\n\n- Spring JPA组件可以创建数据库模板，减少重复代码\n\n- 通过IoC容器，可以清晰地分离逻辑、处理依赖\n\n- ....\n\n当然，引入开发框架会带来额外的学习成本。Spring Boot借鉴了ROR框架中“约定优于配置”的设计理念，进行了大量的改造，实现了框架的“开箱可用”，有效降低了学习成本。\n\n本章会使用一个微服务为例，介绍Gradle + Spring Boot的基础集成。在此基础上，我们会介绍几个与框架紧密相关的内容：RPC框架、数据库、Redis的集成。\n"
},
{
"path": "src/ch02-ms-dev1/database1.md",
"content": "# Spring Boot集成SQL数据库1\n\n从银行的交易数据到打车订单，衣食住行，都离不开数据库的存储。\n\n在接下来的两个小节中，我们将通过3种不同的技术，在Spring Boot中集成MySQL数据库。\n\n- JDBC\n\n- MyBatis\n\n- JPA (Hibernate)\n\n本节的前半部分，我们将通过Docker快速搭建MySQL的环境，随后介绍JDBC的集成方式。\n\n## 搭建MySQL实验环境\n\n本书的重点是讨论微服务实战，我们直接使用Docker的方式，快速搭建实验环境。\n\n如果你想部署在生产环境，请参考官方[部署文档](https://dev.mysql.com/doc/mysql-installation-excerpt/8.0/en/linux-installation.html)。\n\n首先，请确认已经成功安装了Docker：\n\n```shell\ndocker ps \nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\n```\n\n若尚未安装Docker，可以参考[官方文档]([Install Docker Engine | Docker Documentation](https://docs.docker.com/engine/install/))。\n\nMySQL的Docker运行脚本如下：\n\n```bash\n#!/bin/bash\n\nNAME=\"mysql\"\nPUID=\"1000\"\nPGID=\"1000\"\n\nVOLUME=\"$HOME/docker_data/mysql\"\nMYSQL_ROOT_PASS=\"123456\"\nmkdir -p $VOLUME \n\ndocker ps -q -a --filter \"name=$NAME\" | xargs -I {} docker rm -f {}\ndocker run \\\n --hostname $NAME \\\n --name $NAME \\\n --volume \"$VOLUME\":/var/lib/mysql \\\n --env MYSQL_ROOT_PASSWORD=$MYSQL_ROOT_PASS \\\n --env PUID=$PUID \\\n --env PGID=$PGID \\\n -p 3306:3306 \\\n --detach \\\n --restart always \\\n mysql:8.0\n```\n\n如脚本所述：\n\n- 使用官方的8.0镜像启动Docker\n\n- 退出后自动重启\n\n- 暴露3306端口到本机\n\n- 设置Volume盘到~/docker_data/mysql路径下\n\n- root密码123456(请务必更改为安全密码)\n\n执行后的效果：\n\n```bash\ndocker ps\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\nfeb2838197a6 mysql:8.0 \"docker-entrypoint.s…\" 46 hours ago Up 7 hours 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp mysql\n```\n\n启动成功后，我们尝试连接数据库，新建库并授权给用户：\n\n```bash\nmysql -h 127.0.0.1 -u root -p\n\n> CREATE DATABASE homs_demo;\n> CREATE USER 'HomsDemo'@'%' identified by '123456';\n> GRANT ALL PRIVILEGES ON homs_demo.* TO 'HomsDemo'@'%';\n```\n\n尝试用新用户登录：\n\n```bash\nmysql -h 127.0.0.1 -u HomsDemo -p homs_demo\n```\n\n若能成功登录，我们创建本书实验所需的表：\n\n```sql\nCREATE TABLE `users` (\n `id` bigint NOT NULL AUTO_INCREMENT,\n `name` varchar(64) NOT NULL,\n PRIMARY KEY (`id`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;\n```\n\n这里我们创建了表users，有两个列：id和name。\n\n温馨提示：我们使用utf8mb4字符集，如果用utf8是会有坑，可以参考[这篇文章]([掘金](https://adamhooper.medium.com/in-mysql-never-use-utf8-use-utf8mb4-11761243e434))。强烈推荐你对所有的数据表，都设置为utf8mb4。\n\n## Spring Boot 集成 JDBC操作MySQL\n\n我们先通过集成jdbc的方式操作MySQL数据库。\n\n首先在server项目的build.gradle中添加依赖\n\n```groovy\nimplementation 'org.springframework.boot:spring-boot-starter-jdbc'\nimplementation 'mysql:mysql-connector-java:8.0.20'\n```\n\n上述依赖中：\n\n- spring-boot-starter-jdbc是集成jdbc的starter依赖包\n\n- mysql-connector-java是集成MySQL的驱动\n\n接着，我们配置下数据源：\n\n```yaml\nspring.datasource:\n url: jdbc:mysql://127.0.0.1:3306/homs_demo?useUnicode=true&characterEncoding=UTF-8&useSSL=false\n username: HomsDemo\n password: 123456\n hikari:\n minimumIdle: 10\n maximumPoolSize: 100\n```\n\n上述配置分为两部分：\n\n- spring.datasource.url / username / password定义了MySQL的访问链接\n\n- hikari是数据库连接池的配置。\n\nHikari是Spring Boot 2默认的链接池，[官方性能评测优秀](https://github.com/brettwooldridge/HikariCP-benchmark)。这里我们配置了minimumIdle(最小连接数)和maximumPoolSize(最大连接数)两个选项。更多配置参数可以参考[官方文档]([GitHub - brettwooldridge/HikariCP: 光 HikariCP・A solid, high-performance, JDBC connection pool at last.](https://github.com/brettwooldridge/HikariCP#gear-configuration-knobs-baby))。\n\n经过上述的组合配置后，对应DataSource对应的Configuration会自动激活，并注册一系列的关联Bean。\n\n下面让我们使用它访问MySQL数据库：\n\n```java\n@Repository\npublic class UserRepository1Impl implements UserRepository {\n\n @Autowired\n protected NamedParameterJdbcTemplate db;\n\n private static RowMapper ROW_MAPPER = new BeanPropertyRowMapper<>(User.class);\n\n @Override\n public Optional create(User user) {\n String sql = \"INSERT INTO `users`(`name`) VALUES(:name)\";\n SqlParameterSource param = new MapSqlParameterSource(\"name\", user.getName());\n KeyHolder holder = new GeneratedKeyHolder();\n if (db.update(sql, param, holder) > 0) {\n return Optional.ofNullable(holder.getKey().longValue());\n } else {\n return Optional.empty();\n }\n }\n\n @Override\n public Optional getUser(long id) {\n String sql = \"SELECT * FROM `users` WHERE `id` = :id\";\n SqlParameterSource param = new MapSqlParameterSource(\"id\", id);\n try {\n return Optional.ofNullable(db.queryForObject(sql, param, ROW_MAPPER));\n } catch (EmptyResultDataAccessException e) {\n return Optional.empty();\n }\n }\n\n @Override\n public Optional getUserByName(String name) {\n String sql = \"SELECT * FROM `users` WHERE `name` = :name\";\n SqlParameterSource param = new MapSqlParameterSource(\"name\", name);\n try {\n return Optional.ofNullable(db.queryForObject(sql, param, ROW_MAPPER));\n } catch (EmptyResultDataAccessException e) {\n return Optional.empty();\n }\n }\n}\n```\n\n在上面的代码中，我们自动装配了\"NamedParameterJdbcTemplate\"，然后用它访问MySQL数据库：\n\n- 读请求使用db.query，配合RowMapper做类型转化\n\n- 写请求使用db.update，配合KeyHolder获取自增主键\n\n使用JDBC访问MySQL的方式，优点和缺点是完全一样的：使用显示的SQL语句操作数据库。\n\n优点：直接、方便代码Review和性能检查\n\n缺点：SQL编写过程繁琐、易错，特别是对于CRUD请求，效率较低\n"
},
{
"path": "src/ch02-ms-dev1/database2.md",
"content": "# Spring Boot集成SQL数据库2\n\n## Spring Boot 集成 MyBatis操作MySQL\n\nMyBatis是一款半自动的ORM框架。由于某国内大厂的广泛使用，MyBatis在国内非常火热(在国外其热度不如Hibernate)。\n\n首先还是集成依赖：\n\n```groovy\nimplementation 'org.mybatis.spring.boot:mybatis-spring-boot-starter:2.2.0'\nimplementation 'mysql:mysql-connector-java:8.0.20'\n```\n\n套路与jdbc类似，但starter并不是官方的了，而是mybatis自己做的starter，感兴趣的可以来[这里](https://mvnrepository.com/artifact/org.mybatis.spring.boot/mybatis-spring-boot-starter/2.2.0)看下具体组成(会有惊喜)。\n\n接下来是yaml配置环节：\n\n```yaml\nspring.datasource:\n url: jdbc:mysql://127.0.0.1:3306/homs_demo?useUnicode=true&characterEncoding=UTF-8&useSSL=false\n username: HomsDemo\n password: 123456\n hikari:\n minimumIdle: 10\n maximumPoolSize: 100\n\n# mybatis extra\nmybatis:\n configuration:\n map-underscore-to-camel-case: true\n type-aliases-package: com.coder4.homs.demo.server.mybatis.dataobject\n```\n\n不难发现，数据库链接的定义复用了jdbc的那一套，MyBatis的定义分3行，如下：\n\n- configuration：开启驼峰规则转化\n\n- type-aliases-package：mapper文件存放的包名\n\n更多MyBatis的配置选项可以参考[这里]([mybatis-spring-boot-autoconfigure – Introduction](https://mybatis.org/spring-boot-starter/mybatis-spring-boot-autoconfigure/))\n\n接着，我们定义Mapper，在MyBatis中，Mapper相当于前面手写的Repository，定义如下：\n\n```java\npackage com.coder4.homs.demo.server.mybatis.mapper;\n\nimport com.coder4.homs.demo.server.mybatis.dataobject.UserDO;\nimport org.apache.ibatis.annotations.Mapper;\nimport org.apache.ibatis.annotations.Param;\nimport org.springframework.stereotype.Repository;\n\n/**\n * \n * Mapper 接口\n *
\n *\n * @author author\n * @since 2021-09-09\n */\n@Repository\n@Mapper\npublic interface UserMapper {\n\n @Insert(\"INSERT INTO users(name) VALUES(#{name})\")\n @Options(useGeneratedKeys = true, keyProperty = \"id\")\n long create(UserDO user);\n\n @Select(\"SELECT * FROM users WHERE id = #{id}\")\n UserDO getUser(@Param(\"id\") Long id);\n\n @Select(\"SELECT * FROM users WHERE name = #{name}\")\n UserDO getUserByName(@Param(\"name\") String name);\n\n}\n```\n\n你可能会奇怪：这不是接口(interface)么，并没有实现？\n\n是的，通过定义@Repository和@Mapper，MyBatis会通过运行时的切面注入，帮我们自动实现，具体执行的SQL和映射，会读取@Select、@Options等注解中的配置。\n\n经过上述介绍，你可以发现：\n\nMyBatis可以直接通过注解的方式快速访问数据库，(相对于JDBC的)精简了大量无用代码。\n\n同时，MyBatis依然需要指定运行的SQL语句，这与JDBC的方式是一致的。虽然有些繁琐，但可以保证性能可控。\n\n如果你在网上搜索\"MyBatis Spring集成\"，会找到大量xml配置的用法。\n\n在一些老项目中，xml是标准的集成方式。在这种配置方式下，配置繁琐、代码量大，即使借助\"MyBatisX\"等插件，也依然较为复杂。\n\n因此，除非你要维护遗留的老项目代码，我都建议你使用(本文中)注解式集成MyBatis。\n\n## Spring Boot集成 JPA 操作MySQL\n\nJPA的全称是Java Persistence API，即持久化访问规范API。\n\nSpring也提供了集成JPA的方案，称为 Spring Data JPA，其底层是通过Hibernate的JPA来实现的。\n\n首先集成依赖：\n\n```groovy\nimplementation 'org.springframework.boot:spring-boot-starter-data-jpa'\nimplementation 'mysql:mysql-connector-java:8.0.20'\n```\n\n与前面类似，不再重复介绍。\n\n接着是配置：\n\n```yaml\n# jdbc demo\nspring.datasource:\n url: jdbc:mysql://127.0.0.1:3306/homs_demo?useUnicode=true&characterEncoding=UTF-8&useSSL=false\n username: HomsDemo\n password: 123456\n hikari:\n minimumIdle: 10\n maximumPoolSize: 100\n\n\n# jpa demo\nspring.jpa:\n database-platform: org.hibernate.dialect.MySQL8Dialect\n hibernate.ddl-auto: validate\n```\n\n在MySQL连接上，我们依然复用了Spring DataSource的配置。\n\njpa侧的配置为：\n\n- database-platform：设置使用MySQL8语法\n\n- hibernate.ddl-auto：只校验表，不回主动更新数据表的结构\n\n接着，我们来定义实体(Entity)：\n\n```java\n@Entity\n@Data\n@Table(name = \"users\")\npublic class UserEntity {\n\n @Id\n @GeneratedValue(strategy = GenerationType.IDENTITY)\n private long id;\n\n // @Column(name = \"name\")\n private String name;\n\n public User toUser() {\n User user = new User();\n user.setId(id);\n user.setName(name);\n return user;\n }\n\n}\n```\n\n这里我们将UserEntity与表\"users\"做了关联。\n\n接下来是Repository：\n\n```java\n@Repository\npublic interface UserJPARepository extends CrudRepository {\n\n Collection findByName(String name);\n\n}\n```\n\n我们继承了CrudRepository，他会自动生成针对UserEntity的CRUD操作。\n\n此外，我们还定义了1个额外函数：\n\n- findByName，通过隐士语法规则，让JPA自动帮我们生成对应SQL\n\n从直观感受上，JPA比MyBatis更加“高级” -- 一些简单的SQL都不用写了。\n\n但天下真的有免费的馅饼么？我们先卖个关子。\n\n## JMJ应该选哪个\n\n经过这两节的介绍，你已经掌握了JDBC、MyBatis、JPA三种操作数据库的方式。\n\n在实战中，究竟要选哪个呢？\n\n从易用性的角度来评估，我们可以得出结论：JPA > MyBatis > JDBC\n\n那么从性能的角度来看呢？\n\n我们使用wrk做了(get-by-id接口的)简单压测，结论如下：\n\n| | 读QPS |\n| ------- | ---- |\n| JDBC | 457 |\n| MyBatis | 445 |\n| JPA | 114 |\n\n这里，你会惊讶的发现：\n\n- JDBC和MyBatis的性能差别不大，在5%以内\n\n- JPA(Hibernate)的性能，居然只有其余两种方式的1/3 \n\n如此差的性能，真的让人百思不得其解，我尝试打印了SQL和执行耗时，并没有发现什么异常。\n\n更进一步的，我们尝试用指定SQL的方式，替换了自动生成的接口，如下\n\n```java\n@Repository\npublic interface UserJPARepository extends CrudRepository {\n\n @Query(value = \"SELECT * FROM users WHERE id = :id\", nativeQuery = true)\n Optional findByIdFast(@Param(\"id\") long id);\n\n}\n```\n\n这次的压测结果是：447，性能基本和JDBC持平了。但是这种NativeSQL的用法并没有使用自动生成SQL的功能，没有发挥Hibernate本来的功效。\n\n所以，我们认为，锅在于Hibernate自动生成SQL的逻辑耗时过大。\n\n当然，Hibernate也不是一无是处，针对多层关联，建模复杂的场景，使用Entity做映射，会更加方便。\n\n让我们回到前面的问题上：JMJ应该选哪个？\n\n- 如果对性能有极致要求，建议JDBC或者MyBatis。\n\n- 如果建模场景复杂，嵌套密集，且对性能要求不高，可以选用Hibernate。\n"
},
{
"path": "src/ch02-ms-dev1/gradle.md",
"content": "# Gradle构建工具配置\n\n构建工具解决了依赖管理、打包流程、项目结构工程化等问题，是现代软件开发中的必备工具。\n\nGradle是一款Java开发语言的构建工具，兼容POM以来，使用Groovy作为描述语言，构建速度快、可拓展性强，是大量项目的首选。\n\n在本节中，我们将介绍Gradle的基本用法与配置。\n\n## Gradle的下载与安装\n\n我们使用稳定版7.2，你可以在[官网](https://gradle.org/releases/)下载二进制版本。\n\n解压缩后，需要将二进制目录加入你的PATH路径：\n\n```shell\nexport PATH=$PATH:HOME/soft/gradle/bin/\n```\n\n然后执行gradle，查看是否安装成功\n\n```shell\ngradle -v\n\n------------------------------------------------------------\nGradle 7.2\n------------------------------------------------------------\n\nBuild time: 2021-08-17 09:59:03 UTC\nRevision: a773786b58bb28710e3dc96c4d1a7063628952ad\n\nKotlin: 1.5.21\nGroovy: 3.0.8\nAnt: Apache Ant(TM) version 1.10.9 compiled on September 27 2020\nJVM: 1.8.0_291 (Oracle Corporation 25.291-b10)\nOS: Mac OS X 10.16 x86_64\n```\n\n## 修改Gradle的Maven仓库镜像\n\ngradle的依赖使用了Maven的仓库。由于众所周知的原因，这些仓库在国内的速度并不稳定，我们需要将仓库切换成国内镜像。\n\n修改~/.gradle/init.gradle文件如下：\n\n```\n// project\nallprojects{\n repositories {\n mavenLocal()\n maven { url 'https://maven.aliyun.com/repository/public/' }\n maven { url 'https://maven.aliyun.com/repository/jcenter/' }\n maven { url 'https://maven.aliyun.com/repository/google/' }\n maven { url 'https://maven.aliyun.com/repository/gradle-plugin/' }\n maven { url 'https://jitpack.io/' }\n }\n}\n\n// plugin\nsettingsEvaluated { settings ->\n settings.pluginManagement {\n\n // Clear repositories collection\n repositories.clear()\n\n // Add my Artifactory mirror\n repositories {\n mavenLocal()\n maven {\n url \"https://maven.aliyun.com/repository/gradle-plugin/\"\n }\n }\n }\n}\n```\n\n解释下文件配置：\n\n- 上半部分：将maven中央仓库、jcenter仓库都修改为国内镜像(阿里云)，并增加了jitpack仓库(后续章节会使用)。\n\n- 下半部分：将gradle插件仓库修改为国内镜像，这部分是必须的，不要忘记。\n\n我们可以通过一个简单的脚本，检查配置是否生效\n\n验证脚本build.gradle\n\n```groovy\ntask listrepos {\n doLast {\n println \"Repositories:\"\n project.repositories.each { println \"Name: \" + it.name + \"; url: \" + it.url }\n }\n}\n```\n\n执行验证：\n\n```\ngradle listrepos\n\nRepositories:\nName: MavenLocal; url: file:/Users/coder4/.m2/repository/\nName: maven; url: https://maven.aliyun.com/repository/public/\nName: maven2; url: https://maven.aliyun.com/repository/jcenter/\nName: maven3; url: https://maven.aliyun.com/repository/google/\nName: maven4; url: https://maven.aliyun.com/repository/gradle-plugin/\nName: maven5; url: https://jitpack.io/\nIntelliJ\n```\n\n## gradle-wrapper生成\n\ngradle-wrapper是用于执行gradle的脚本 + 精简版的gradle二进制文件。\n\n既然已经有了gradle，为什么还要单独弄一个wrapper出来么？\n\n- 方便没有安装gradle的环境执行构建(例如打包机)\n\n- 支持多版本gradle的快速切换(实现nvm的效果)\n\n初始化gradle项目时，执行如下命令：\n\n```shell\ngradle init\n```\n\ngradle会生成如下wrapper相关文件：\n\n```shell\n├── gradle\n│ └── wrapper\n│ ├── gradle-wrapper.jar\n│ └── gradle-wrapper.properties\n├── gradlew\n├── gradlew.bat\n└── settings.gradle\n```\n\n建议将上述文件一并加入git仓库中，以防出现版本兼容问题。\n\n## IntelliJ IDEA中配置Gradle\n\nIntelliJ IDEA是一款功能强大的IDE，是许多Java程序员的首选。\n\nIDEA默认支持Gradle，请确保配置正确：\n\n\n\n上方的Gradle配置文件默认路径，请维持默认配置，使用家目录下默认的。\n\n下方的Gradle版本，推荐使用默认选项(gradle-wrapper.properties)，即使用项目路径下gradle-wrapper.properties指定的版本。\n\n经过上述配置，我们已经搭建了Gradle的构建环境。在下一节，我们会在此基础上集成Spring Boot框架。\n"
},
{
"path": "src/ch02-ms-dev1/redis.md",
"content": "# Spring Boot集成Redis内存数据库\n\n常规的业务数据，一般选择存储在SQL数据库中。\n\n传统的SQL数据库基于磁盘存储，可以正常的流量需求。然而，在高并发应用场景中容易被拖垮，导致系统崩溃。\n\n针对这种情况，我们可以通过增加缓存、使用NoSQL数据库等方式进行优化。\n\nRedis是一款开源的内存NoSQL数据库，其稳定性高、[性能强悍]([How fast is Redis? – Redis](https://redis.io/topics/benchmarks))，是KV细分领域的[市场占有率冠军](https://db-engines.com/en/ranking/key-value+store)。\n\n本节将介绍Redis与Spring Boot的集成方式。\n\n## Redis环境准备\n\n与前文类似，我们使用Docker快速部署Redis服务器。\n\n```bash\n#!/bin/bash\n\nNAME=\"redis\"\nPUID=\"1000\"\nPGID=\"1000\"\n\nVOLUME=\"$HOME/docker_data/redis\"\nmkdir -p $VOLUME \n\ndocker ps -q -a --filter \"name=$NAME\" | xargs -I {} docker rm -f {}\ndocker run \\\n --hostname $NAME \\\n --name $NAME \\\n --volume \"$VOLUME\":/data \\\n -p 6379:6379 \\\n --detach \\\n --restart always \\\n redis:6 \\\n redis-server --appendonly yes --requirepass redisdemo\n```\n\n在上述脚本中：\n\n- 使用了最新的redis 6镜像\n\n- 开启\"appendonly\"的持久化方式\n\n- 启用密码\"redisdemo\"\n\n- 端口暴露为6379\n\n我们尝试连接一下：\n\n```bash\nredis-cli -h 127.0.0.1 -a redisdemo\n```\n\n成功！(如果你没有redis-cli的可执行文件，可以到[官网下载](https://redis.io/download))\n\n## Redis的缓存使用\n\nSpring提供了内置的Cache框架，可以通过@Cache注解，轻松实现redis Cache的功能。\n\n首先引入依赖：\n\n```groovy\nimplementation 'org.springframework.boot:spring-boot-starter-data-redis'\nimplementation 'org.springframework.boot:spring-boot-starter-json'\nimplementation 'org.apache.commons:commons-pool2:2.11.0'\n```\n\n上述依赖的作用分别为：\n\n- redis客户端：Spring Boot 2使用的是[lettuce](http://github.com/lettuce-io/lettuce-core)\n\n- json依赖：我们要使用jackson做json的序列化 / 反序列化\n\n- commons-pool2线程池，这里其实是data-redis没处理好，需要额外加入，按理说应该集成在starter里的\n\n接着我们在application.yaml中定义数据源：\n\n```yaml\n# redis demo\nspring:\n redis:\n host: 127.0.0.1\n port: 6379\n password: \"redisdemo\"\n lettuce:\n pool:\n max-active: 50\n min-idle: 5\n```\n\n接着我们需要设置自定义的Configuration：\n\n```java\npackage com.coder4.homs.demo.server.configuration;\n\nimport com.fasterxml.jackson.annotation.JsonAutoDetect;\nimport com.fasterxml.jackson.annotation.PropertyAccessor;\nimport com.fasterxml.jackson.databind.ObjectMapper;\nimport com.fasterxml.jackson.databind.ObjectMapper.DefaultTyping;\nimport com.fasterxml.jackson.databind.jsontype.impl.LaissezFaireSubTypeValidator;\nimport org.springframework.cache.annotation.CachingConfigurerSupport;\nimport org.springframework.cache.annotation.EnableCaching;\nimport org.springframework.cache.interceptor.KeyGenerator;\nimport org.springframework.context.annotation.Bean;\nimport org.springframework.context.annotation.Configuration;\nimport org.springframework.data.redis.cache.RedisCacheConfiguration;\nimport org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer;\nimport org.springframework.data.redis.serializer.RedisSerializationContext;\n\nimport java.time.Duration;\n\n/**\n * @author coder4\n */\n@Configuration\n@EnableCaching\npublic class RedisCacheCustomConfiguration extends CachingConfigurerSupport {\n\n @Bean\n public KeyGenerator keyGenerator() {\n return (target, method, params) -> {\n StringBuilder sb = new StringBuilder();\n // sb.append(target.getClass().getName());\n sb.append(target.getClass().getSimpleName());\n sb.append(\":\");\n sb.append(method.getName());\n for (Object obj : params) {\n sb.append(obj.toString());\n sb.append(\":\");\n }\n sb.deleteCharAt(sb.length() - 1);\n return sb.toString();\n };\n }\n\n @Bean\n public RedisCacheConfiguration redisCacheConfiguration() {\n Jackson2JsonRedisSerializer