r“烟囱式”系统
1）重复功能建设和维护带来的重复投资。
2）打通“烟囱式”系统间交互的集成和协作成本高昂。
3）不利于业务的沉淀和持续发展。
采用“烟囱式”方式建设的系统体系，企业中一个业务领域的数据和业务往往就被打散在不同的系统中，采用系统打通的方式解决了眼前相关业务间的交互问题，但这样的方式治标不治本。
SOA
SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
只有这些服务在业务发展的过程中得到持续的演进、功能逐步完善和增强，最终变为企业在该领域最为专业的IT资产时，才能真正达到SOA中所描述的业务的快速响应，更好地支持业务创新。不要让SOA的项目就沦为了实现多个系统间的集成
阿里共享事业部五大价值定位
1.开放:实现对内，对外的开放
2.服务:服务能力不断提升
3.滋养:业务滋养
4.稳定:专注、专业带来稳定
5.数据:线上，线下数据产品创新
大数据平台存在问题
1.数据分布广、格式不统一、不标准
2.缺少能基于数据有业务建模能力的专家。
最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。
服务中台核心共享服务平台，需要分布式服务框架支撑
传统单应用存在问题
1）项目团队间协同成本高，业务响应越来越慢。
2）应用复杂度已超出人的认知负载。
3）错误难于隔离
4）数据库连接能力很难扩展。
5）应用扩展成本高。
服务化架构
1.降低不同模块开发团队间的协同成本，业务响应更迅捷
2.大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块。
3.避免了个别模块的错误给整体带来的影响。
4.❑业务拆分后解放了对单数据库集群连接数的能力依赖。
5.做到针对性的业务能力扩容，减少不必要的资源浪费。
架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题
共享服务中心的架构目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。所以，所有的原则和方法都是为了这些目标服务的，“以终为始”再来看服务中心建设的原则和方法就会明确很多。
服务划分原则
1．高内聚、低耦合原则
2．数据完整性原则
3．业务可运营性原则
4．渐进性的建设原则
第五章数据库分库分表
1.数据尽可能平均拆分
3．尽量减少事务边界
创建异构索引表__六个月分表，归档
第六章异步化与缓存原则
1.业务流程异步化
2.数据库事务异步化
3.事务与柔性事务
核心是体现数据库ACID（原子性、一致性、隔离性和持久性）属性
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
BASE是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）
第七章打造数字化运营平台
解决三大问题
1.如何对每天发生的几千亿次服务调用出现报错时快速定位问题，
2.如何实时监控到服务的运行状态是否正常，
3.如何给运营团队关注的业务指标提供实时呈现以供他们进行实时的精准营销，
埋点，日志
通过对服务调用时的埋点信息的收集，以及TraceID和RCPID的串联作用，给运维人员在Web界面上清晰还原出每一次业务过程
第八章，打造平台稳定性能力
1.限流和降级。.限流平台主要涵盖了授权、限流、降级、调用统计监控四大功能模块：
❑授权——通过配置白名单与黑名单的方式对HSF的接口和方法进行调用权限的控制；
❑限流——对特定资源进行调用的保护，防止资源的过度调用；
❑降级——判断依赖的资源的响应情况，当依赖的资源响应时间过长时进行自动降级，并且在指定的时间后自动恢复调用；
❑监控——提供了全面的运行状态监控，实时监控资源的调用情况（QPS、响应时间、限流降级等信息）。
2.流量调度
流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。
3.全链路压测平台
a．基础数据抽取;b．链路与模型构造;c.链路验证;d.业务改造;e.数据平台;f.流量平台;g.影子表;h.中间件改造;i.安全机制
4.业务一致性平台__业务审计平台
第9章 共享服务中心对内和对外的协作共享
1．服务的数量和业务覆盖范围越来越大
2．应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
3．服务安全控制层缺乏
4．开发体验很不友好，产品在接入流程，开发使用手册建设非常之差
典型的互联网公司，非常强调快速响应、敏捷、业务驱动、试错
5．整体服务体系缺乏一个统一的服务治理层
离线模式下的路径是：服务消费者（业务开发者）→各种渠道（电话、旺旺、小二）→服务提供方→服务
共享服务平台建设之后的流程：服务消费者（业务开发者）→共享服务平台→服务→服务提供者
服务是一个名词，通常我们说的服务是指服务端暴露出来的一种服务接口，与服务消费者相对应，其代表了服务端一个具体的能力
服务化是一个动词，它更像是一个商业策略，核心是从产品能力转化直接服务客户的能力。产品能力是从产品出发，以产品为核心；服务化是以面向客户的服务为核心。
我们把服务化实施划分为API as Service、Product as Service、Solution as Service三个阶段
业务中台是前端应用所需服务的提供者，前端应用是业务中台服务的消费者，同时前端应用对于业务中台也是需求的提供者，两者之间不单单是服务提供者和消费者间的关系，也是在服务不断对接过程中，两者相辅相成，共同发展，业务能力不断专业化的过程。业务中台除了提供对前端应用的高效支持，同时也承载了业务持续沉淀和创新的使命。
业务中台与前端应用协作的模式。
1．业务中台对前端核心业务的紧密沟通机制。2．建立分歧升级机制。3．岗位轮转推动真正换位思考。4．业务持续沉淀及共建模式。
业务中台绩效考核
1．服务稳定是重中之重。2．业务创新推动业务发展。3．服务接入量是衡量服务价值的重要考核。4．客户满意度促动服务的提升