微服务应用程序总结

1  代码库--所有的应用程序代码和服务器供应信息都应该处于版本控制中。每个微服务都应该在源代码控制系统中有自己独立的代码存储库。

2  依赖---通过构建工具，如Marven（java） ，明确的生命应用程序使用的依赖项。应该使用期特定版本号声明第三方Jar依赖项，这样能够保证微服务始终使用相同版本的库来构建。

3 配置--将应用程序配置（特别是特定于环境的配置）和代码分开存储。应用程序配置不应该于源代码在同一个存储库中

4 后端服务--微服务通常通过网络和数据库或者消息系统进行通信。如果这样做，如果这样做，应该确保随时可以将数据库的实施从内部管理的服务换成第三方服务。

5构建、发布、和运行--保持部署的应用程序的构建、发布、运行完全分开，一单代码被构建开发人员就应该在运行时对代码进行修改。任何更改都需要回退到构建过程并重新部署。一个已构建的服务是不可变的并且是不能被改变的。

6 进程-微服务应该是始终无状态的。他们可以在任何超时被杀死或者被代替，而不用担心一个服务实例的丢失导致数据丢失

7 端口绑定--微服务在打包的时候应该是完全独立的，可运行的微服务中要包含一个运行时引擎。运行服务时不需要单独的Web或者应用程序服务器。服务应该在命令上自动启动，并通过公开的HTTP端口立即访问

8 并发--需要扩大时，不要依赖单个服务中的线程模型，。相反要启动更多的微服务实例并水平伸缩。这并不需要在微服务中使用线程，但不要将其作为伸缩的唯一机制。横向扩展而不是纵向扩展

9 可任意处理--微服务是可任意配置的，可以根据需要启动和停止。应该最小化启动时间，当操作系统收到Kil信号时，进程应该正常关闭。

10 开发环境和应用环境等同--最小化运行的所有环境（包括开发人员的台式机）之间存在的差距。开发人员应该在本地开发时使用与微服务运行相同的基础设施。这意味着服务在环境之间部署的时间应该是数小时而不是数周。代码被提交后，应该被测试，然后尽快从测试环境一直提升到生产环境。

11 日志--日志是一个事件流。当日志被写出时他应该可以流式传输到诸如splunk或者fluentd这样的工具。这些工具将整理日志并将它们写入中央位置。微服务不应该关心这种情况发生的机制。开发人员应该在它们被写出来的时候通过标准输出直观的观察日志。

12 管理进程--开发人员通常不得不针对它们的服务执行管理任务（数据转移或转换）。这些任务不应该是临时的，而应该通过源代码存储库管理或者脚本来管理。这些脚本应该是可重复的，并且在每个运行环境中是不可变的（脚本代码不会针对每个环境进行修改）