当红架构Cloud Native，怎么搭建才能成为上云助攻手？(2)

之前在网易,对稳定性要求很高的产品,其发布流程通常都很曲折,主要原因在于环境的不一致.陈谔的建议是使用Docker实现环境的一致性,Docker容器完整虚拟化了Linux操作系统,将业务代码与运行环境装箱为Docker容器发布到生产环境,差异仅仅为外部注入的配置(如数据库地址等),容器内部文件在开发环境一旦发布则不再变化,从而保证开发环境与生产环境一致.

3、服务化的思维

工程化是做业务架构,建立一个高效团队的基础,接下来要考虑的就是服务化的思维.微服务是当下很流行的概念,采用微服务确实能为应用的迭代和架构带来很多好处.但服务化的架构会带来额外的负担,如果一个项目还处在初期阶段,我们的建议则是服务化思维先于服务化架构.

• 运维成本：一旦服务多了,环境搭建、故障诊断、运维的工作量都会成倍增加；
• 服务拆分之后,各个服务间的生命周期是不一致的,要做生命周期的分离,就需要处理更多的异常.服务间存在更多的约束,还是异步的,如依赖关系、版本,要保证消息能够可靠地到达那里；
• 另一方面,还会有分布式事务的问题,虽然解决起来不难,但是会侵入你的业务.

虽然业务初期,不适合服务化,但应该为后续的服务化做一些准备,否则后面想拆分的时候会变得非常困难：

• 提取Service API,理解业务中的服务抽象；
• 数据库设计的时候就考虑服务的划分；
• 避免跨服务事务,对跨服务事务进行标记；
• 如果项目发展起来,遇到的第一个问题通常是数据库会挂掉,所以在业务初期就做分库分表是很有必要的；
• 选择事务支持更好的数据库,如果你用缺乏事务支持的数据库做业务的后端,当你要做服务化拆分或分布式事务的时候,可能会比用MySQL的痛苦很多.

4、实施微服务

随着业务的壮大,是否要采用微服务,就要去衡量微服务带来的收益是否大于成本?

收益

• 控制迭代更新的影响域,而单体架构很难评估patch的影响范围；
• 加速迭代,提交代码心里负担小,迭代也能加快；
• 隔离局部故障；
• 防止代码架构层面的腐化,比如开发过程中为了赶进度,可能会把原有的架构推倒重来.如果用微服务架构,最多只需要将自己负责的那个模块重新设计.

成本

• 更多的依赖(eg: ZooKeeper,MQ),要做一个注册中心；
• 运维复杂度,几十个服务发布更新,运维的复杂度必然会上升；
• 技术实现的侵入性,在这个过程中难免要用到一些微服务化的框架,虽然对代码的侵入性不大,但对架构的侵入性还是不可避免的.

降低实施成本

• 良好的工程化,不要给运维的工作带来很多困难；
• 使用基于云端托管的PaaS服务；
• 使用基于云端托管的编排服务,帮你去做集群化的运维和管理的工作.

基于Kubernetes简化微服务实施

利用基于Kubernetes的基础设施可以简化微服务,一方面Kubernetes提供了基于域名的服务发现：

• 使用VIP+域名暴露服务：对比“注册中心”,采用域名服务具有更小的侵入性,更少的依赖
• 支持名称空间隔离,简化测试环境部署

Kubernetes还可以做基于iptables的透明RPC分发：

• 无需在程序中访问注册中心获取成员列表进行软负载均衡；
• 无需内网负载均衡层次增加网络开销.

比如,服务A访问服务B的虚拟IP VIP,利用iptables做DNAT,转成B中的所有成员,服务A可以直接,并利用probability特性按权重分发请求,比域名做轮转的负载均衡效果要好,因为iptables可控,域名不可控.

用Kubernetes还可以让你获得自动化运维能力：

• 自动扩缩容
• 自动故障处理(重试、迁移)
• 自动化滚动更新,通过健康检查与滚动的配合实现无缝更新
• 还可以基于Service 抽象实现蓝绿发布

Kubernetes以解耦的基础服务层的方式提供了对服务化的支持,避免了代码实现层面的耦合,通过云端托管Kubernetes服务能够将实现服务化的成本大幅降低.而且Kubernetes对业务没有侵入性,实现服务化的代价相对会比较小,后面业务变得非常重,需要细粒度控制时,再用到其它框架也没有什么影响.

我们深度整合了Docker技术和Kubernetes集群编排技术,所以网易云中会有一个Kubernetes Master,所有租户的业务都可以使用这个Master,不用用户自己维护.

5、DevOps

前面讲到的都是云原生相关的技术,实际上实现云原生还需要一些研发、运维和组织架构上的方式调整,比如DevOps.DevOps的出现是为了解决运维角色与开发角色的矛盾,运维追求的是可用率优先,而开发希望应用能快速更新迭代.

DevOps 与微服务

微服务架构能够支持更高频的迭代,降低更新迭代的风险,这与DevOps的目标是一致；但是微服务架构也会给运维带来成倍的工作量,可基于DevOps分散运维操作,而不是集中依赖少量运维角色.

实施DevOps

实施DevOps需要CI/CD、编排、故障诊断等工具链的支持,同时需要运维实现从操作到审计的职能转换,运维工作前置,在前期和开发团队合作.很多运维还需要开发工具,提高运转效率.

基于DevOps工具链支持微服务架构

1)Jenkins-容器-镜像仓库-服务编排

Pipeline as Code：实施服务化后持续集成的复杂度成倍增加,需要定义大量的流程,包含大量Jobs,以代码的方式管理Pipeline能够支持审计,有效管理复杂性并降低维护成本.

2)日志服务-分布式跟踪系统-性能管理服务

日志服务：Kafka+ELK套件,以网易云为例自动完成容器日志收集,并提供订阅接口可对接ELK.

分布式跟踪系统：在微服务架构下必须要做到与单体架构同样的服务请求的调用路径跟踪能力,才能够有效定位故障.可参考的框架有Zipkin,需要对RPC框架等做instrumentation,在调用过程中携带额外的头信息.

（编辑：ASP站长网）