本文是根据潘志伟老师在 ArchSummit 全球架构师峰会上的演讲整理出来的，讲述了如何从 0 开始构建一个亿级请求的系统的历程，其中包括了服务拆分、微服务测试、容量预估以及上线的流程。稳定的系统不仅要依赖好的架构设计，而且需要对核心代码，高频访问模块精雕细琢，看似不起眼的一些小优化，长期积累起来就会有质的变化，正所谓细节决定成败，做架构也是同样的到底。
1. 微服务实施的前置条件
很多技术人员在听到企业技术架构要转型，打算从单体架构往微服务架构转型，得知消息后就异常的兴奋，认为自己马上又能学到新的技术了，开始去关注到底是选型哪种技术架构，并运行框架提供的 Demo，认为成功运行 Demo 就具备了实施微服务的条件了，等待公司一声令下，就踏上微服务之旅了。其实这是一种典型的技术人员考虑事情的思维，通过过往的经验来看，更重要的是在实施微服务之前全员统一思想、充分培训、 以及工程结构标准化。
统一思想： 因为在准备实施微服务的时候，首要条件就是获得高层的认可，因为涉及到组织结构的调整以及后续人力资源的增补，另外在新架构上线后难免会出现问题，这个时候需要得到高层的支持。另外，在单体应用中其组织机构包括开发部、测试部、运维部、DBA 部，每个部门各司其职由高层统一指挥，看似很非常合理的组织结构，但是在项目或者迭代实际过程中会花费大量的时间去跨部门沟通，形成了孤岛式功能团队。
充分培训： 微服务架构的开发人员具备“精”、“气”、“神”的特质，否则在后续发展阶段一定会出现各种难题。“精”是指熟悉业务，熟悉选型的开发框架，而不仅限完成 demo 运行，必须要熟悉原理，最好能熟悉源码，做到面对问题不慌，“气”是指大家对微服务架构这件事情的思想认知一致，能够在一个频道上对话，“神”是指需要了解其理论知识，比如什么是服务治理，什么是服务自治原则，明白为什么需要这样而不是那样。
工程结构标准化： 所有服务交付服务，从代码风格比如类的命名，module 命名以及启动方式都是一致的，减少研发人员对于未知的未知而产生的担心。
在正式开始微服务之前，有必要了解下云原生的 12 要素，它针对微服务的一些设计思想做了充分的归纳和总结，云原生 12 要素的内容如下：
- 基准代码：一份基准代码（Codebase），多份部署（deploy）
- 依赖：显式声明依赖关系
- 配置：在环境中存储配置
- 后端服务：把后端服务 (backing services) 当作附加资源
- 构建、发布、运行：严格分离构建和运行
- 进程：以一个或多个无状态进程运行应用
- 端口绑定：通过端口绑定 (Port binding) 来提供服务
- 并发：通过进程模型进行扩展
- 易处理（快速启动和优雅终止可最大化健壮性）
- 环境等价：开发环境与线上环境等价
- 日志
- 管理进程
其中第一条需要特别注意，它要求基准代码或者软件制品只允许有一份，可以部署到多个环境，不因为环境的改变而需要重新编译或者针对不同的环境编译多个制品。记住，测试即交付的原则，即你测试的软件制品和交付到生产的软件制品是一样的。重点强调环境配置和制品库分离，如果是测试环境的配置，那么软件运行起来就是测试环境，如果是生产环境的配置，那么软件运行起来就是生产环境。发现很多程序员都喜欢把配置文件写到工程里面，例如 application-dev.properties、application-test.properties、application-prod.properties 等，然后在系统启动的时候增加 spring.profiles.active=dev 来说明环境，其实这种做法是非常的不优雅，首先违背了云原生 12 要素第一个条件，其次测试环境、生成环境的所有的配置信息都暴露在代码中，容易导致信息泄露，最后增加运维部署难度，一旦环境变量标识错误就会导致软件运行失败。
