一、架构即代码
    微服务系统的架构往往指的是服务之前的调用和依赖关系。架构即代码指的是通过DSL语言（如Graphviz等工具）来描述架构图，并将其放在代码库中以版本化的方式管理起来。

    二、接口即代码
    服务的API接口随着系统架构的演进而不断发生变动。通过Swagger之类的工具可以通过DSL方便地定义API的详细信息并以可视化的方式呈现。可以将Swagger生成的YAML代码保存在微服务的代码库中。Java微服务中可以引入swagger-springmvc插件，内嵌了Swagger-UI，直接访问即可查看服务的API信息。

    三、本地运行服务
    开发人员希望在本地运行服务，便于代码调试和功能测试。
    对于纯前端的工程，可以通过npm start的方式直接启动服务。
    对于后台服务，开发环境、镜像环境、测试环境有着不同的配置中心，当开发机器能够同其他服务所在的主机通信的时候，配置好测试环境的注册中心、数据库等的地址和端口等信息即可。

    四、OnePage文档
    微服务的开发人员需要知道微服务的基本信息。通常将其记录在文档中，称为“OnePage文档”。主要包含以下信息
    微服务综述：名称，基本功能，消费者，API
    微服务SLA：可用性，不可用的时间段
    架构相关：微服务依赖的组件、服务、数据库等
    运行环境：测试环境、预生产环境、生产环境的访问地址和访问方式等
    开发相关：开发环境配置方式、本地启动方式、调试方式、开发流程等
    测试相关：
    流水线相关：持续集成地址、构建包存储地址等
    运维相关：
    常见问题链接：

    五、前后端分离
    前后端分离指的是后端提供数据接口，前端页面请求各个服务API，聚合数据并展现，完成交互逻辑。

    前后端分离的有点是明显的。
    前后端分离使得前后端的职责更为清晰，前端负责展示，后端提供数据接口。有助于提升开发效率，降低维护成本。
    前后端分离有助于性能提升。前端可以存放在文件服务器上，系统运行时可以独立地对后端进行伸缩。

    前后端分离也带来了额外的挑战。
    适配问题。需要适配不同的客户端。
    协作问题。需要对前后端之间的协作进行额外的测试。
    SEO问题。把需要SEO的内容放在前端的HTML中。
    跨域问题。

    下面提供一个典型的前后端分离的案例。
    前端以静态文件的方式保存在文件服务器S3上。index.html需要在CSS/JS等资源文件上传之后上传。
    前端的访问日志上传到Splunk上，方便统计和追踪。
    使用CDN加速页面加载。
    后端API为典型的在EC2上部署的架构。

    六、微服务与安全