只看了第一、二、三和第七章
业务系统的主要挑战：高可用、海量、复杂的业务逻辑交织在一起，重点就是
复杂业务系统的解耦问题。
运维的目标：全程进行动态感知与管理，不仅要有全部的监控能力，更要根据业务流量进行业务的优雅降级，确保系统高可用。
↑↓←→
架构演变：烟囱式架构→分布式架构→共享式架构
烟囱.jpg
烟囱式架构：
来源:IT系统建设早的企业内部系统烟囱林立，互联网转型难的根节所在。
三大弊端：
1）重复功能建设和维护带来的重复投资。
2）打通“烟囱式”系统间交互的集成和协作成本高昂。最贵的就是集成平台建设
3）不利于业务的沉淀和持续发展。
最大的浪费不是重复建设，而是不断重复建设。
早期往往一个新业务的上线除了数据可以被重复使用之外，服务却不能被重复使用。其实服务的重用将比数据重用带来更多好处，数据只是原始生产资料，服务则包含逻辑，是工厂的加工车间，如果加工过程也一样可以复制，将带来生产效率的大幅度提升。
再好的技术和框架如果不给企业带来业务价值，就没有太大意义
IT信息中心配合业务部门完成业务目标中IT系统的建设，在现有的模式下已经被更高的领导层定位成了业务支持的部门，是一个花钱的成本中心。
共享业务事业部的发展史.png
共享业务事业部的发展史2.png
何为懂业务?
懂业务是指，能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。
能成为业务领域专家，对业务发展有创新想法和独到见解。
这才能说自己是懂业务的。
SOA架构的核心价值——服务重用
把不同业务系统，都会共同牵涉的部分抽取出来
服务最不需要“业务稳定”！一个服务如果一味追求功能的不变，一定程度上就是固步自封，这样的做法是在逼着其他系统去建同样的“轮子”，当越来越多的系统都采用自建“轮子”的方式满足自身系统对这部分业务的需求时，之前的这个服务慢慢就少有人问津，当有更好的服务出现或该服务完全满足不了当前业务发展的要求时，也就是这个服务离开历史舞台的时刻。
2014年时的淘宝业务已经非常复杂，而且各个业务遍布到不同的服务中心和应用中，就出现了一种问题：在整个交易流程（包含下单、收款、退款等）中，出现个别业务的结果不一致，也就是说整个交易流程中技术上没有任何错误和异常，但从业务的角度出现了偏差，比如用户购买了航旅的商品，在会员中心中添加了相关的积分，但商品进行退款操作后，因为航旅部门、交易中心、用户中心协作的问题，导致了积分没有从用户的账号中退减回来；又比如因为个别商铺的营销活动发生调整，应用逻辑中的处理bug，导致用户所下主订单的总金额与该主订单中子订单商品金额不同。其实这样的问题在单个业务服务和应用点上都很难感知到，而从底层共享业务事业部的角度，就能非常清楚地看到产生这类问题的原因。
业务创新如同创业一样，一旦成功，给企业带来的回报可能是超出预期的，但也意味着有失败的风险。在传统企业中，一定是需要申请预算和立项来落实业务创新的想法，传统“烟囱式”的系统建设方式对项目投入的资金和资源自然不会少。在要申请大量资源而且项目还有失败的可能性的情况下，有业务创新想法的人在考虑到失败带来的影响时，一定会权衡其中的利弊，大多数人会选择退缩，只有少部分有魄力的人顶着巨大的压力走上了业务创新之道。
小的前端团队具备以下特征（人数是7个人的团队协同效率是最高的）：
1）团队协同效率最高。
2）对战机（商机）的把握更加敏锐。
3）调整方向更加快捷。
4）一旦发现正确目标， 全力投入扩大战果。
大数据项目落地现存问题：
1）数据分布广、格式不统一、不标准。
2）缺少能基于数据有业务建模能力的专家。
3）业务数据的闭环难实现（个人补充）
业务+技术的复合型人才如何培养：
共享服务体系能很好地帮助企业信息部门培育出懂业务的专家，这些人员自身在拥有不错的技术功底的同时，逐步提升业务上的能力，具备这样能力模型的人员才有希望成为能发挥大数据平台价值的“数据科学家”。
抓懂技术的人培养业务能力
为什么“去中心化”服务架构成为今天绝大多数互联网平台所采用的服务框架。
1）项目团队间协同成本高，业务响应越来越慢。
2）应用复杂度已超出人的认知负载。 牵一发而动全身
3）错误难于隔离。
4）数据库连接能力很难扩展。→2007年，淘宝在应用代码方面做了足够好的优化
5）应用扩展成本高。
“给飞行中的飞机换发动机”
基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造工作。
作用：
·降低不同模块开发团队间的协同成本，业务响应更迅捷。
·大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块。
·避免了个别模块的错误给整体带来的影响。
·业务拆分后解放了对单数据库集群连接数的能力依赖。
SOA的主要特性：
·面向服务的分布式计算。
·服务间松散耦合。
·支持服务的组装。
·服务注册和自动发现。
·以服务契约方式定义服务交互方式。
从当企业的业务进行了服务化之后，两种架构给业务带来的影响进行对比。
1.服务调用方式的不同带来业务的响应和扩展成本
2.“雪崩”效应束缚了“中心化”服务框架的扩展能力
阿里巴巴当时在对多种通信协议和数据序列化组件等测试中，Netty+Hession的组合在互联网高并发量的场景下，特别是在TPS上达到10w以上时，性能和效率远比REST或者Web Service高。
微服务架构的典型特征的描述：
·分布式服务组成的系统。
·按照业务而不是技术来划分组织。
·做有生命的产品而不是项目。
·智能化服务端点与傻瓜式服务编排。
·自动化运维。
·系统容错。
·服务快速演化。
疑难点:
·微服务化的应用架构如何进行有效的服务管控。具体：服务链路跟踪、链路分析、实时业务指标的监控等问题，整体服务平台的管控能力
·分布式事务难题。
·自动化运维和平台稳定性。
·微服务的服务设计。
·原有组织架构是否满足微服务架构持续发展的需要。
正所谓“罗马不是一天建成的”，企业如果要构建微服务体系架构，不要期望靠一个项目就能建立起来，需要多一份耐心，通过服务能力在业务发展过程中的不断沉淀，当业务的能力沉淀到一个阶段后，才能真正感受到微服务架构给企业的业务发展带来的长远价值，而这份价值体现出来时，会给企业带来业务高速发展的翅膀，真正让企业的业务发展飞得更快、飞得更远。
6.异步化与缓存原则
业务流程异步化:
通过服务异步调用的方式让业务流程中业务逻辑上允许同步执行的服务同时被调用，从而解决了大量远程服务线性调用带来的性能问题。
6.1 业务流程异步化
使用消息中间件的方式实现了业务异步化
(消息MQ)
6.2 数据库事务异步化
解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。(TCC)
6.3 事务与柔性事务
1.CAP理论
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
“一致性” 指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。一致性指在一个系统中不论数据存放在何处，作为一个整体应是完整和一致的。在分布式系统中，数据通常不会只有一份，用户对数据进行一定的修改操作（增/删/改）之后，为了保证数据的一致性，那么应该对所有数据进行相同的操作并且这些操作应该是同时成功或者同时失败的。
如果一个存储系统可以保证一致性，那么客户读写的数据完全可以保证是最新的。不会发生两个不同的客户端在不同的存储节点中读取到不同副本的情况。
“可用性” 指用户在访问数据时可以得到及时的响应。可用性是关于一个系统能够持续不间断使用的问题，严格的定义是高性能可用性。这意味着一个系统从设计到实施都应该能够提供可持续的操作（如读写操作），无论是操作冲突，还是软硬件部分因为升级而导致失效。但是可用性并不意味着数据的一致性，比如读取到的数据是过期数据或脏数据，但对于用户仍有返回数据的情况下，仍然可以被认为是可用的。
同时可用性的要求包含时效性，对于大多数应用而言，超过一定响应时间的服务是没有价值的或者价值量低的。例如，阿里巴巴和Google这样的公司很细小的响应延迟都会对公司的盈利造成损失。
“分区容错性” 指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。
·“基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
·“柔性状态”是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQL Replication的异步复制也是一种柔性状态体现。
·“最终一致性” 是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
高可用=系统构建在多机=分布式系统
高性能=分布式系统的副产品
·单机锁=时间消耗（微秒级 ）
·跨多机的锁=时间消耗（毫秒级 ）=1000倍单机时间消耗
系统处理的吞吐率与资源上的时间消耗成反比（参考阿姆达尔定理）
4.柔性事务如何解决分布式事务问题
（1）引入日志和补偿机制
为避免单点，事务日志是记录在分布式节点上的，数据REDO/UNDO日志一般记录在业务数据库上，可以保证日志与业务操作同时成功/失败。通常柔性事务能通过日志记录找回事务的当前执行状态，并根据状态决定是重试异常步骤（正向补偿），还是回滚前序步骤（反向补偿）。
（2）可靠消息传递
消息投递只有两种模式：1）消息仅投递一次，但是可能会没有收到；2）消息至少投递一次，但可能会投递多次
多次的要求消息处理程序必须实现幂等（幂等=同一操作反复执行多次结果不变）
（3）实现无锁
·避免事务进入回滚。
·辅助业务变化明细表。
比如对资金或商品库存进行增减处理时，可采用记录这些增减变化的明细表的方式，避免所有事务均对同一数据表进行更新操作，造成数据访问热点，同时使得不同事务中处理的数据互不干扰，实现对资金或库存信息处理的隔离。
商品当前库存数量=商品表中的库存数量-预减明细表中该商品对应明细表中库存数量之和。
·后面提到的乐观锁。
5.柔性事务在阿里巴巴内部的几种实现
（1）消息分布式事务
通过消息进行事务异步的方式，保证了前后两个数据库事务同时执行成功或失败，保持了事务的一致性，同时因为避免了传统两阶段提交事务方式对数据长时间的资源锁定，所以数据库整体的吞吐率和性能大大超过传统的分布式事务方式。
避免出现事务回滚
如果一个事务上下文中超过两个事务操作后，因为事务的回滚逻辑变得非常复杂而不可控，所以在这样的场景下只能进行正向的事务补偿，在某些业务场景下会给带给客户不同的体验。
（2）支付宝XTS框架
XTS是TCC（Try/Confirm/Cancel）型事务
补偿型事务
·Try阶段主要是对业务系统做检测及资源预留。
·Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
·Cancel阶段主要是在业务执行错误需要回滚的状态下，执行业务取消，预留资源释放。
一个事务里面包含多次事务操作，优先TCC
新一代分布式事务平台TXC
·TXC完全能满足之前分布式事务平台所提供的对于事务服务高可用和事务最终一致性的基本业务要求。
·标准模式下无需开发人员自行进行事务回滚或补偿的代码，平台支持自动按事务中事务操作的顺序依次回滚和补偿。
·易用性是TXC的主要目标，在保证事务完整性的前提下，标准模式可不修改应用的代码，同时也提供之前平台中所提供的事务重试以及自定义事务模式。
从本质来说，将原来传统事务场景下，由数据库提供的锁机制提升到了TXC服务端进行了实现，这样相比于数据库锁的实现成本更加轻量，加上TXC本身服务能力的扩展能力，最终在同样实现事务隔离性的前提下，大大提升了整体的数据库处理吞吐率。
TXC如何实现事务自动回滚。
1）用户在向TXC服务器发起事务请求后，进入到数据库的操作时，会对该分支事务在TXC服务器上进行注册。当资源管理器捕捉到SQL的请求后，会对SQL语句进行SQL解析，如果是执行Insert/Delete/Update的SQL操作，则会针对该SQL语句构造出对应的SQL查询语句，将当前SQL请求要修改的数据先从数据库中获取，以Undo日志的方式保存起来，用于将来回滚。
2）进行实际的SQL语句的执行，在SQL执行完毕以后，会再次通过查询方式获取到修改后的数据，并保存为Redo日志，用于业务回滚前脏数据的校验。
3）当SQL的执行和Undo/Redo日志作为一个本地事务提交给数据库的同时，也会更新分支事务状态。当整个事务成功提交后，则会删除Undo/Redo日志。
7.关于柔性事务的总结
绝大部分场景下，我们都不需要用两阶段提交这样低效的方式来解决分布式事务问题。
·应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时。
·远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用。
两阶段提交的方案可以保证最强的ACID要求，开发者因此不需要仔细考虑自己的应用到底可以接受什么级别的ACID；同时，两阶段提交的方案开发简单，开发者只需要指定事务的边界即可。而最终一致性方案往往意味着更高的事务处理性能及处理吞吐率，但有些实现方案需要开发人员更全面地了解前端业务以实现事务的正向补偿或反向回滚，也会付出有损事务隔离性的代价。所以一定要在业务上精确分析自己的ACID需求，寻找性能与ACID的折中点，采取最合适的方案。
分布式缓存产品是Tair --对比 Redis
乐观锁和悲观锁
如果采用数据库的悲观锁（比如select语句带for update）模式，则会给订单处理带来很大的性能阻塞，所以会采用乐观锁的方式实现商品库存的操作。
实现的方式也比较简单，也就是在最后执行库存扣减操作时，将事务开始前获取的库存数量带入到SQL语句中与目前数据库记录中的库存数量进行判断，如果数量相等，则该条更新库存的语句成功执行；如果不相等，则表示该商品的库存信息在当前事务执行过程中已经被其他事务修改，则会放弃该条update的执行
Update auction_auctions set quantity=#inQuantity#，where auction_id=#itemId# and quantity=#dbQuantity#
网友评论