时间：   |   分类：       |   阅读： 4399 字 ~9分钟

ArchSummit

参加ArchSummit北京站已有一周时间，一直没有时间来梳理一下。整体来说，这次的北京之行，不是很满意，可能是这类会议听多的原因，感觉ArchSummit的质量是越来越差了，没有什么新鲜感，觉得不值那6K的价格。

组织不足

12月份的北京已是非常的干冷，可能由于我在南方呆久了，一到北京是极其地不适应，在北京三天多的时间，嘴唇开裂，到现在还没有完全好干净。离开北京的那一天，正好又感受了一下北京正宗的霾，帝都的人们活得真不容易啊。

为什么说ArchSummit组织不足呢？InfoQ也算是组织过多次大型会议的公司，但这一次比我之前参加InfoQ组织的任何会议都差，更无法与阿里组织的云栖会议相比。一个是以组织会议赚钱，一个是以个会议来打造生态。这次的ArchSummit是在北京国际个会议中心举行，每个分会场我都差不多的参加过，明显感觉组织不足:

  • 每个分会场演讲时，大门紧闭，空间质量非常的差，又没有充足的通风设备，感觉非常的窒息。
  • 工作人员能力不行，第一天下午，有几个分会议室由于投影没有准备好，拖时半个多小时，也不见中途主持人来了说一声，最后连声道歉都没有。
  • 几个分会场的投影效果差，灰蒙蒙的看不清楚。
  • 连个矿泉水瓶上都是广告，并且不是每个位置都摆放好水，而是需要自己去指定位置去拿。有的分会场甚于连矿泉水都没有见到，准备的份数太少，6K的价格连个水都喝不到。
  • 就餐地方太小（又是自助餐），效率低下，大量的人员挤在走廊上，我是差不多等了30多分钟才能进餐厅吃饭。大量的人员挤在一起存在安全风险。

两天的ArchSummit大会日程比较紧凑，再加上大多数时候有六个专题在并行，因此每个人能够真正去听的课程不会太多。我们也是只能选择地去听，但是每个演讲介绍不足，有些演讲名字高大上，听了之后，感觉有点上当，部分讲师存在水分，这里就不直说了。

不过，参加ArchSummit大会，还是听到一些业内公司的技术分享，尤其是互联网企业，在应用新技术方面还是比较超前的。相对我们电信行业来说，我们遇到的问题有些是相似的，甚至部分问题的解决办法也与我们曾经想过的一些方案类似，只是他们早已经落地并且做到极致了。有很多东西对我们值得参考，可以说从开源使用、技术形态，运作方式，远远走在我们的前面了。

PaaS平台

目前稍具规模的互联网公司，都会自建数据中心。而互联网的业务又有如下特点：

  • 业务需要快速上线，唯快不破
  • 业务形态众多，迭代周期快
  • 数据处理量大，海量请求和高并发的挑战

支撑业务的发布，上线，运维，都需要对业务应用的全生命周期管理，各个公司都有一套平台，他们或多或少都能称得上内部的PaaS平台。而PaaS平台核心：

分布式框架

首先是《蚂蚁金服金融级PaaS平台构建之道》分享，阿里在国内技术一直算是走到前列。这次带来的演讲，蚂蚁金服的分布式服务注册中心（DSR），与阿里其它系的Dubbo，HSF都差不多。他们的目标都要解决应用服务化后，服务注册发现问题，可以说是未来PaaS平台中，服务注册发现将成来PaaS的核心中的核心。

后一场听了《主流容器SDN技术与微服务架构实践》，来自七牛的分享。虽然演讲的内容是容器的SDN技术（算不上大范围的SDN），也同时点到微服务架构。虽然他们所讲的容器方案都说是自研的，但整体上感觉与K8S的设计是相似，甚至像Pod之类的概念来也是借鉴来的。在容器环境下的同时也要解决分布式的服务发现问题，他们采用是DNS机制。服务路由上支持L4与L7的负载均衡，对业务无侵入。基于安全组的服务Discovery，虽然没听太明白，感觉跟K8S的Proxy机制是差不多的。

中间件服务

在《蚂蚁金服金融级PaaS平台构建之道》中初步介绍了分布式消息(DMS)、分布式数据源（DDS），分布式事务（DTS）的一些使用场景与技术特点。在云环境下，中间件服务必不可少，让业务应用只关注自己的业务逻辑。中间件服务要面对的是一个复杂、不断变化的计算环境。抽象出业务的公共能力服务化。使用中间件服务，可以简化业务应用在一些通用技术的成本，如数据一致性，安全控制，高性能，可靠性等。而中间件技术正在呈现出业务化、服务化、一体化的趋势发展。高可用性，自管理性，业务适应性是当前中间件服务面临的挑战。

弹性扩展

在云计算中，引入虚拟化技术，采用弹性伸缩是老生常谈了，一键式按需弹性，基于性能采集的自动弹性。听了《微众银行基于自主可控技术的分布式架构实践》，给我对弹性带了新的思考。互联网+的应用是：海量用户，海量交易，海量数据。这要求对系统在架构设计上充分考虑容量的扩展性，性能的扩展性。

微众的架构特点是分布式松耦合架构+一主两从节点强制同步的架构。在分布式松耦合架构是按客户群来水平分割，一个节点上涵盖多个客户业务。分布式多节点是分散风险，如果有节点受损，也是部分客户有影响。而每个节点上又采用一主两从节点强制同步，来提高整个系统的冗余。整个系统以客户为单元可控分布，将客户量、交易频繁度与系统负载之间的关系解耦。随着客户量增加或客户交易频繁度的增加,系统负载也会随着增加：

  • 横向扩展(Scale Out)解决用户量增加
  • 纵向扩展(Scale Up)解决交易频繁度增加

并且严格要求，横向扩展只能解决用户量问题，不能通过纵向扩展来解决用户量问题，反之亦然。

容灾备份

云计算环境下，容灾备份也是需要重点考虑的，容灾设计强调的是系统对外界环境影响具备快速响应能力，尤其是当发生灾难性事件并对IDC节点产生影响时，能够具备节点级别的快速恢复能力，保障系统的持续可用。像微众介绍IDC2.0中提到的：

  • 数据库三中心集群化部署
  • 三数据副本强同步
  • 应用多中心多活部署
  • 应用多中心多实例多活部署

蚂蚁金服金服提到的：

  • 两地三中心
  • 异地多活

支付宝有一个专题《支付宝的高可用与容灾架构演进》，我觉得有意思的是其中的单元化与容灾。单元化应该是微服务化中一种具体运用吧。什么是支付宝的单元化：

  • 核心业务,核心剥离：数据按照UserID拆分,多机房部署,调用封闭,部分数据,不共享
  • 非核心业务,长尾独立：不能按照UID拆分，核心不依赖长尾

单元化的实现思路：

  • 水平拆：交易、支付、账务等,每个单元只有部分数据
  • 上层单元化改造：从DB层往上延伸水平拆分概念,包括应用层到入口层

在容灾同步上，是基于单元化的多中心同步，这已打破我们对原有容灾备份的认识，基于单元化的容灾同步，可以细粒度的控制，解决数据一致性和时效性问题：

  • 基于DB同步的数据复制：延时非敏感业务的异地复制方案;部分业务数据,可忍受3s时效性延迟(比如大部分的配置 数据)
  • 基于消息系统的数据复制：对于延时非常敏感的业务,更低延时的实现方案;上层基于应用进行复制,减少延时。底层 DB主备同步同时进行

高效运维

开发团队快节奏的版本迭代，以及服务的快速上线的要求，驱动着PaaS平台要提供出更为高效的运维服务。高效运维的思路是建立以 应用服务 为核心的管理标准体系。把运维能力服务化(API)，使运维的能力无处不在。高效运维，综合几个公司的介绍主要需要如下几个系统设计：

  • 发布系统：负责应用服务的上线，应用服务的资源管理，扩容，权限管理，支持Beta发布，灰度升级。
  • 监控系统：通用+自定义监控配置,运维+开发可以时刻关注自己的服务状态和质量。
  • 全链路系统：复杂的分布式系统，一次点击，几十次的RPC调，需要全链路跟踪，出了问题,如何快 速定位到故障点。
  • 限流与降级：限流,Web层,防止被流量打垮；降级,App层(服务化),保障核心应用
  • 容量评估：基于全链路的压测手段、数据分布的模拟方法、关键场景调用量预估
  • 蓝绿发布：即多站点的灰度。具体操作流程：切流（将待发布机房流量切走）-> 机房发布（待发布机房全应用并行发布）-> 引流验证 （逐步按规则引流至100%）-> 流量交换（将全部流程切换到已发布机房）-> 机房发布（另一个机房全应用并行发布）-> 分流还流（分流规则还原，两机房各50%）

服务化

今年IT界是对服务化异常的火爆，系统的稳定和流畅依赖好的应用架构，服务化治理如何规划和落地，是众多厂商系统的痛点。

首先是来自1号店订单系统对SOA化的分享，SOA是一种架构模式,是设计原则,不是技术规范。狭义的SOA：Service化， 标准化、模块化、组件化。广义的SOA：模式、原则、思想。

  • Service化：1）分层结构，基础Service不含业务逻辑,只封装基本的数据操作。业务(聚合)Service封装业务逻辑甚至是全部的业务逻辑。2）Service层次调用，上层可以调用下层、下层不可调用上层、同层间可互相调用，调用链长度不超过3级、不循环调用。

  • 服务粒度划分：1）迷你裙定律。2）细粒度的服务(fine-grained)提供相对较小的功 能单元,或交换少量的数据。细粒度的服务使服务更容易被组装。3）粗粒度的服务(coarse-grained)则是在一个抽象 的接口中封装了独立的业务/技术能力,减少服务请求交互的次数。粗粒度的服务适合更广泛的需求。

再次是来自Twitter的服务化思路分享：

  • 单体：牵一发而动全身
  • 分拆：把单体分成多个模块
  • 服务化：把模块按功能服务化
  • 平台化：模块功能中部分服务化为通用服务，通用服务提供一般化服务，平台化

Docker

在不断寻求性能更好、速度更快、成本更低的云计算核心技术中，容器技术是目前最吸引人注意的技术之一。尽管除去效率、速度和成本等方面的优势以外，容器技术还存在一些安全上需要斟酌的问题，但是其实际表现仍然得到了肯定。还是借用其中的分享内容来说明一下Docker。

在遇到Docker之前：

  • 混乱的环境：Java, Golang, Ruby
  • 混乱的配置：Upstart, authorized_keys, dependency, 各种脚本
  • 混乱的监控：ErrorReporter, Message
  • 混乱的资源：计算资源与预估不匹配

导致的结果是：

  • 环境不匹配导致,测试跟生产不一致
  • 配置混乱导致事故频发
  • 监控不统一导致运维难上加难
  • 资源效率低导致成本很高却达不到相应目标

而Docker具有如下特点：

  • 构建快：应用+运行环境 = 镜像
  • 启动快：容器相比于虚机,更轻量级
  • 迁移快：应用以容器的方式标准化交付,标 准化运行

去年Docker主要是在吵作概念，而今年很多的互联网厂商已在使用Docker，本次Docker中都分享各自针对Docker的一些定制化修改及踩过的各种坑，所遇到的困难和走过的弯路。

当然这些坑不是阻当我们不使用Docker的理由，Dockerk只是一个系统架构优化的承载体。来自Coding.net的分享最后总结的比较好，Docker会对软件，流程带入变革与影响，是否采用Docker，系统都需要关注如下三个方面，只是Docker让你不得不关注他们：

  • 软件架构的升级：微服务、无状态、数据执行分离
  • 研发体系、环境管理理念的升级：容器化、代码化、自动化
  • 资源管理理念的升级：Pet vs Cattle，多留点富余量，迁移能力比压榨能力更重要
0%