去年差不多也是这个时候，我写过一篇《阿里云IoT应用案例》，重点提到了我们对于阿里云IoT SDK的封装并实现自主注册、消息队列规则转发、双向通讯、远程升级和远程控制等功能的设计思路。

最近阿里云盘和Teambition网盘同时出现在市面上，两款产品都来自阿里云智能事业群，据说定位略有不同。其中阿里云盘侧重个人应用，偏生活娱乐，如相册功能，类似百度网盘。而Teambition网盘定位办公协同，类似OneDrive。两套产品都基于阿里云OSS，目前都处于测试阶段。

自2019年加入一家传统生物医疗器械公司以来，我们组建了一支40余人的团队主攻企业数字化转型，做新产品和新业务模式探索。一年多的时间，我们也搭建了一整套基于阿里云的微服务架构的平台体系，包括K8S服务编排、监控预警日志、基于Gitlab和Jenkins的CI/CD等等。此外还使用过Leangoo、Jira、Confluence、企业微信在线文档、NextCloud等协同工具，最后稳定在Jira+Confluence+Nextcloud组合。但由于各个系统不方便打通伴随人员增加，管理压力和安全隐患等问题逐渐暴露出来，所以近期就在考虑用全家桶方案整合各个系统。

最近半年一直在尝试物联网相关技术在传统行业的应用，推动企业数字化转型。结合阿里云和阿里云IoT平台，初步实现了几个主要业务功能，整理分享如下：

1. 共享服务体系搭建

• ESB解决异构系统之间的交互
• 去中心化分布式服务框架除了对于 SOA 特性的实现和满足外，相比中心化服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何 服务路由中介， 避免因为中心点带来平台能力难扩展问题，以及潜在的雪崩影响
• 关于雪崩
  • 企业服务总线架构一旦遇到上面所提到的“雪崩”事故后，故障恢复的时间和成本都非常高昂。因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式则是首先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，再开放服务请求，这样才能恢复系统的运行。但因为着急恢复系统，没有来得及定位之前造成开始服务实例出问题的根本原因，这样的系统恢复运行其实处于一个“脆弱”的状态，之前造成服务实例宕机的问题可能让“雪崩”事故再次上演。
• 微服务架构的典型特征
  • 分布式组成的系统
  • 按照业务划分也不是按照技术划分
  • 做有生命的产品而不是项目
  • 智能化服务端点与傻瓜式服务编排
  • 自动化运维
  • 系统容错
  • 服务快速演化
• 关于微服务的"微"
  • “微服务”中的这个“微”字给很多人带来了很多误解。从字面意思上，“微”会让人联想到一个微服务就应该是功能足够单一，甚至出现一个服务的实现可能只需要几十或者上百行代码的说法，这应该是最误导人的观点。从技术角度出发，确实可以通过简短的代码实现功能单一的服务，但从一个整体架构考虑，如果是以这样的方式实现各个微服务，则在整个服务体系范畴当中包含太多功能边界，那么对于服务运营的分工和边界就很难界定，给服务接下来的持续运营和维护带来困扰；另外拆分过于细化的服务，势必将带来大量无谓的分布式事务调用，给业务的实现带来额外的工作量和风险。

2. 服务中心建设

• 服务中心一定是不断发展的
• 尝试服务化 - 全面服务化 - 服务平台化
• 服务中心的多样性
  • 接口：API
  • 工具：配置服务、管理服务
  • 数据：大数据分析
• 服务中心可以进一步划分
• 服务中心和业务不一定一一对应
• 服务中心划分原则
  • 三个方面
    • 设计
    • 运营
    • 工程
  • 四个原则
    • 高内聚低耦合
    • 数据完整性
    • 业务可运营
    • 持续渐进

3. 数据拆分

• 数据尽可能平均拆分（用户订单和子订单Hash方案） 如果是按照订单ID取模的方式，比如按64取模，则可以保证主订单数据以及相关的子订单、订单详情数据平均落入到后端的64个数据库中，原则上很好地满足了数据尽可能平均拆分的原则。
• 通过采用买家用户ID哈希取模的方式，比如也是按64取模，技术上则也能保证订单数据拆分到后端的64个数据库中，但这里就会出现一个业务场景中带来的一个问题，就是如果有些卖家是交易量非常大的（这样的群体不在少数），那这些卖家产生的订单数据量（特别是订单详情表的数据量）会比其他卖家要多出不少，也就是会出现数据不平均的现象
• 尽可能减少事务边界 所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量，上面示例中就是事务边界大的典型示例，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来以下弊端：
• 系统锁冲突概率高
• 系统难以扩展
• 整体性能差
• 异构索引表避免全表扫描 即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是互联网公司很多时候都采用的一个解决思路：拿空间换时间

4. 异步化

• 业务流程异步化：MQ
• 数据库事务异步化：解决平台性能的核心问题
  • 大事务拆分小事务
  • 降低资源被锁造成的性能瓶颈
• 事务与柔性事务 BASE是指基本可用（BasicallyAvailable）、柔性状态（SoftState）、最终一致性（EventualConsistency）
  • “基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
  • “柔性状态”是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQLReplication的异步复制也是一种柔性状态体现。
  • “最终一致性”是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
• ACID与BASE区别
  • ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型；BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

5. 数字化运营（异常追踪和定位）

• 在每个应用集群的运行环境中，每当应用中进行了远程服务调用、缓存、数据库访问等操作时，都会生成相关的访问日志并保存到应用所在的服务器上。
• 在每一个URL请求都会生成一个全局唯一的ID，鹰眼平台中称为TraceID，这个ID会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的所有日志中。
• TraceID一般包含：
  • IP地址：在淘宝环境可直接映射到前端应用。
  • 创建时间：在存储时用于分区。
  • 顺序数：用于链路采样。

6. 平台稳定性

• 限流和降级 相当于电路上的保险丝，当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台处理能力范围内的业务请求。
• 压测
  • 被压测的单机的关键指标（CPU利用率、系统整体负载、QPS、响应时间等）达到的阀值水位后即自动停止压测，以免对生产环境产生大的影响。
  • 基础数据抽取：模拟尽可能真实
  • 链路和模型：用户的行为不同，代表链路，参数，模型不同，需要综合考虑模拟真实行为
  • 影子表：数据的隔离是全链路压测诞生阶段的一大难题。全链路压测的链路有读有写，并且在线上进行，为了不污染到线上的正常数据，全链路压测在同一个数据库的实例上对数据库表建同样结构的影子表来进行数据的隔离。
  • 安全机制：全链路压测的安全机制分两层：第一层是安全的监控和保护，建立非法流量的监控机制，正常用户访问不了测试数据，测试账户也访问不了正常数据，防止数据错乱；并且设置压测引擎集群的白名单，防止恶意访问；第二层是对压测流量的安全过滤，针对压测流量放松安全策略，使得压测流量不被判别为攻击流量。

7. 服务化野蛮生长面临的问题

• 服务的数量和业务覆盖越来越大 怎么样才能非常高效地找到我需要的服务，并能快速地接入和使用起来？当团队和业务规模小的时候，面对面的交流是最有效的方式，但是当到达一定的数量级的时候，通过人与人之间的互通有无肯定不可行了。
• 应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
• 服务安全控制层缺乏
• 应用不知道哪些下游业务在使用，升级或变更时与依赖方沟通花费大量时间
• 服务被未授权的业务方调用
• 随意发布服务
• 开发体验不友好，产品接入时，开发使用手册，文档建设差
• 整体服务缺乏一个统一的服务治理层
  • 在线化
  • 数据化

我们探讨数字化生存，数字化转型，那么何为数字化转型？为什么要转型？如何去做转型？这是我们探讨话题的最根本的问题。我将结合自身工作经验和行业案例，浅谈这三个问题，旨在抛砖引玉。