这篇文章简单谈下一个云原生应用构建的关键点。
什么叫云原生应用？
简单来说就是满足云原生最佳技术实践和管理实践要求，应用从需求提出开始就使用云原生资源和服务能力，并最终能够持续交付到云平台的应用；同时在该应用交付完成后还需要具备足够的管控治理能力和可观测性。
微服务开发就是云原生应用？
注意微服务只是云原生应用的一个关键技术实践，采用微服务开发是构建云原生应用的必要条件而非充分条件。云原生应用的判断条件是生在云上，并向云持续交付的能力。
比如你采用微服务开发，最终将开发完成的应用，申请虚拟机资源部署到云平台上，那么不能叫云原生应用，不符合上面谈到的重复利用云原生服务，持续向云交付的能力。
从技术服务到BaaS后端服务
在ServerLess无服务器化里面会谈到BaaS后端能力即服务。ServerLess开发期望的就是FAAS开发足够轻，甚至连笨重的开发框架都没有，最终是函数编程并调用后端能力。
企业级应用开发暂时无法做到这点。
云原生强调从资源到服务，那么自然涉及到类似数据库，消息，缓存等各种技术服务能力提供。但是任何传统单体业务系统开发，底层都是一个技术平台。
这个技术平台一般来说包括了通常说的系统管理和流程引擎这两个关键能力。
单体拆分为微服务后，这两个能力必须下沉为后端共性服务提供。
相反，对于数据库，消息反而不是重点。
原因就是你在开发阶段还是采用的传统的自己搭建数据库，JDBC连接等方式，你会发现迁移到云服务后，可以很方便的迁移为云平台提供的数据库服务能力。你需要的仅仅是更换JDBC连接或JMS消息订阅地址。
也就是说对于中间件资源池这种关键技术服务能力迁移很容易实现。
反而是对于类似4A，流程平台等共性平台服务层能力要及早构建，作为PaaS技术服务平台的一个关键组成。
微服务和前后端分离
在很早我谈微服务的时候，一直在说微服务并没有明确指出一定要前后端分离。
如果你是开发的APP移动应用，你会看到APP前端应用和后端服务自然是分离的。而且前端APP也不会再进行拆分。即变成了。
一个前端APP=>多个后端微服务Service
如果你是开发传统PC桌面端的应用，前端通过浏览器访问。那么一个微服务本身是可以包括前端，或者说前后端不分离的。只是为了更好地贯彻横向分层和服务解耦。
即使PC端应用开发也推荐前后端分离开发。
前后端分离开发实际带来几个变化。
其一是团队人员分工更加细化，前端开发人员和后端开发人员本身也分离。其二是前后端分离后更加容易保证后端Service服务的稳定性，不少的需求变更或变化更多的是发生在前端模块。其三是前后端分离后方便我们后续抽象服务编排和组合层能力。
开发阶段只使用SpingBoot
微服务开发框架，大家说的最多的就是SpingCloud，本身具备了微服务开发，运行，管控治理所需要的各种能力。
但是个人提出微服务开发阶段只使用SpingBoot能力。能够确保开发出一个独立的微服务模块，并暴露Rest API接口服务即可。在开发阶段不应该引入太多的微服务管理需求，这些管控治理能力应该是后续通过ServiceMesh服务网格增加边车代理的思路来实现。
东西流量和南北流量
先说下南北流量的问题。在使用基于k8s+docker的容器云平台后，你会看到采用Ingress网关来解决微服务应用内部前端和后端的南北流量问题足够了。
这个时候不需要再使用微服务网关。
而当整个微服务应用需要对外暴露能力的时候，则还需要在上层构建一个API网关来统一实现对外接口暴露和南北流量的统一管控治理。
注意不是简单的通过负载均衡暴露，需要使用API网关的目的还是实现安全，日志，限流熔断等进一步的接口服务治理能力。
而对于东西流量，最佳方式就是ServiceMesh服务网格的边车代理。
特别是配合容器云自动化部署能力，这个Sidecar代理可以在微服务部署阶段自动和微服务部署到一个Pod中实现对东西流量的拦截。在流量拦截后自然可以很方便地实现安全，日志，限流等各种管控能力。
所有简单总结就是一个微服务应用的流量管控问题，是通过k8s Ingress网关解决南北流量+ServiceMesh解决东西流量管控。
通过DevOps实现持续集成和交付到容器云
对于容器云和DevOps本身也是云原生核心要素。
微服务的开发必须要结合DevOps相关技术实践和管理实践，首先要实现了的是敏捷研发管理和CI/CD的持续集成能力。
即整个微服务应用开发生命周期全部都要管理起来。
并通过DevOps来实现和容器云的持续集成和交付，跨环境的迁移能力。云原生应用的一个核心特点就是必须要具备向云服务持续交付的能力。
DevOps我前面文章谈的很多，即使没有构建一个完整的DevOps过程能力支撑平台，也可以是自己整合Jekins，Gitlab，Artifactory，Harbor等关键开源工具，形成基本的可配置，可编排的自动化流水线能力。
在云原生12要素里面也专门提到了应该严格区分构建，发布和运行。
而构建发布，从SIT环境到UAT环境，从UAT到生产环境，本身整个持续集成和交付的过程即通过DevOps来实现统一管理。
构建只能是一次。
