前言微服务的陷阱： 微服务拆分过细，过于强调”small”。 微服务基础设施不完善，忽略了”automated”。 微服务并不轻量级，规模大了之后，”lightweight”不在适应。 针对以上问题，后面将介绍微服务的最佳实践。 服务粒

微服务与SOA关系从以下几个方面来说明二者的关系： 服务粒度 SOA的服务粒度要更粗一点，微服务的粒度要细一点。对于大型企业来讲，“员工管理系统”是SOA的一个服务，而如果采用微服务架构，则“员工管理系统”会拆分成更细的服务，比如“员

前言软件系统与硬件和建筑系统的最大差异就在于软件是可扩展的，而硬件和建筑是不可扩展的。一个硬件生产出来后是不会做修改的，建筑也是一样。 软件系统的这种可扩展性，即是其魅力，也是其难点。其魅力在于我们可以不断的到软件进行扩展，让软件系统拥有更

47-开源项目：如何选择、使用以及二次开发前言软件开发领域有一个流行的原则：DRY,Don’t repeat yourself。即不要重复造轮子。开源项目的主要目的就是共享，其实就是为了大家不要重复造轮子。 引入开源项目可以节省大量的人力和

分层架构分层架构也叫N层架构，是一种常见的架构。通常情况下，N一般大于等于2，比如C/S架构，B/S架构。常见的是三层架构(MVC、MVP)架构，四层架构，五层架构比较少，一般复杂的系统才会用到。 C/S、B/S架构划分的对象是整个业务系统

前言成为架构师是每个程序员的梦想，但是程序员和架构师之间有一个巨大的鸿沟，需要程序员去跨域方能成为架构师，那就是“不确认性”。 对于编程而言，其结果是确定的，但是对于架构是不确定的。架构没有编程那么的的约束，可以使用这种方式去实现，而对各种

异地多活主要是解决系统级别的故障，例如：机器宕机、机房故障、网络故障等。虽然这些故障的影响很大，但是发生概率低。还有一类故障是业务运行中经常遇到的：接口级故障。 接口级故障的表现是系统没有宕机、网络也没有中断，但业务却出问题了。例如：业务访

跨城异地设计的4个步骤： 第一步：业务分级按照一定的标准，对业务进行分级,挑选出核心业务,只为核心业务设计异地多活，降低方案整体复杂度和成本。 常见的分级标准： 访问量大的业务 核心业务 产生大量收入的业务 第二步：数据分类挑选出核心业

45-架构重构内功心法第二式：合纵连横前文讲到的是有的放矢，需要架构师透过问题现象看到问题本质，找出真正需要通过架构解决的核心问题，而不是想一次性解决所有的问题。 下文讲述架构重构的合纵连横。 合纵架构重构是一个大动作，持续时间比较长，而且

前言存储高可用方案的本质通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用。其复杂性主要在于如何应对复制延迟和复制中断带来数据不致的问题。对于一个存储高可用方案需要从以下几个方面分析： 数据如何复制？ 各节点的职责是什么？ 如何

46-架构重构内功心法第三式：运筹帷幄前言通常情况下，需要重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发。到了真正要开始重构的时候，架构师识别出系统关键的复

应用场景异地多活的关键点在于异地、多活，其中异地就是指地理位置上不同的地方，多活就是指不同地理位置上的系统都能够提供业务服务。判断一个系统是否异地多活，需要满足以下二个条件： 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的