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

之前在网易,对稳定性要求很高的产品,其发布流程通常都很曲折,主要原因在于环境的不一致.陈谔的建议是使用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可控,域名不可控.

（编辑：网站开发网_马鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!