目前大型或者超大型企业的IT平台都是烟囱式的系统架构，缘由是企业内部为了迎合业务发展不停地打造各种系统，也导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗了人力、财力还有时间。但打通烟囱式系统间的交互和协作成本高昂，各大企业不得不借助ESB产品，构建企业服务总线来解决各系统间的交互问题。
然而随着业务的发展和迭代，企业的业务架构也逐渐发生变化，仅打通各系统间的交互和协作问题是不够的，还需要逐渐整合现有的各个系统，使得企业能从战略、组织、制度、流程和业务等方面进行持续的迭代，完善企业的结构和运转方式，使企业能够达到现在和未来的目标，进而根据企业运营模式的需求而建立系统化、标准话的业务流程和智能的信息化平台，持续迭代企业的业务蓝图。
如果仅打通各个系统之间的交互和协作不够，那要如何整合现有各个系统呢？
首先我们来分析下借助ESB“中心化”的服务架构缺点，其一：ESB“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点，而这个中心点的能力是
很难进行扩展的，导致这中心会成为一个瓶颈；其二：现有系统为基于SOA架构的单体系统，在做业务过程编排、应用集成方面表现很好，但随着业务的发展，系统变得复杂，模块耦合度高，关联依赖复杂，牵一发而动全身，不利于业务创新和迭代；其三：多个系统中的重复功能无法进行服务共享，造成一物多码、数据不同步等问题，存在隐患。
其次我们来看看成功的“大中台，小前台”信息化建设案例。
2015年阿里巴巴集团启动了中台战略，目标是要构建符合互联网大数据时代的，具有创新性、灵活性的“大中台、小前台”的机制，即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。整体内容如下：
“大中台、小前台”架构主要集中在业务共享服务层，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀，降低研发成本，提高研发效率。打破了产品壁垒，之前是系统之间要数据，现在是都去找共享服务中心要数据，共享服务中心提供统一的，标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西，可以快速孵化新的产品，试错成本低，产品敢于创新，敢于拥抱变化，原来追竞争对手都很困难，现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展，技术和业务能力能够沉淀积累。
“大中台、小前台”与微服务的关系
微服务体现去中心化、天然分布式，与大中台战略思想类似，是战略的具体实现方式的一种。现有架构师可以学习这种模式来解决企业本身的应用高并发、高可用、运维等难题，也是现有互联网经典架构，毕竟是经过阿里实践过的，除了BAT，Uber、网易、美团、京东等互联网公司都在很早前就实现了平台微服务化。
微服务是将企业通用服务按业务化分成一个个单体服务，增强可用性、服务易扩展、减少开发成本、减少服务发布对整个平台的影响。微服务是一种思想，实现有很多方式，企业转由单个系统转向微服务就要考虑很多问题，比如技术选型、业务拆分问题、高可用、服务通信、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试，以及调度和部署等等，这并非一些简单招数能够化解。
微服务框架必须能够达到借助虚拟化平台，能够按需创建机器并调整大小，借助基础设施的自动化从一台机器扩展到多台，拥有业务监控预警、异常熔断等等功能，现有框架有Dubbo和SpringCloud，Dubbo是RPC服务治理框架，和SpringCloud一样具备服务注册、发现、路由、负载均衡等能力。
微服务架构所包含的内容：
既然微服务架构如此优秀，单体系统升级到微服务架构时将面临哪些挑战：
一：如何拆解服务
使用什么样的方法拆解服务？业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法，但是这些都缺乏实施基础。我们必须从一些软件设计方法中寻找，面向对象和设计模式适用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起作用。
Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义，这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说，这是一个最合理的解决拆分问题的方案，透过限界上下文（Bounded Context，下文简称为BC）这个概念，我们能将实现细节封装起来，让BC都能够实现SRP（单一职责）原则。而每个微服务正是BC在实际世界的物理映射，符合BC思路的微服务互相独立松耦合。
二：失败处理的成本
随着服务的数量增加，系统失败的几率会大幅增加。
每一个服务的失败都有可能导致故障。虽然我们的目标是期望每个服务都能够互不依赖，自适应，高度容错，但是必须找到有效的方式来确保服务可用。
因此，处理失败的成本大幅增加。
三：优势资源的竞争
当有成千上万的服务时，资源如何分配？从业务角度分析，哪个服务的优先级高？哪个团队应该优先获得更优秀的资源？包括但不限于优秀的工程师、资金、软件、硬件等等。
任何时候，资源都不是免费的。
当只有几个微服务时，这些问题都不会是问题，但随着服务数量的增加，这种协作与竞争的关系会愈发明显。
四：独立性与技术债
随着微服务的大热，组织中许多人员对微服务过度追捧。
很多人认为微服务对应着松散的组织结构，只要能独立交付，团队可以做任何他们想做的。从技术角度而言，技术日新月异的变化，会产生各种大大小小的技术债，而随着采用微服务化在技术上的多样性，将变得难以维护。
微服务确实意味着自由与独立。但在大规模的组织中，过度的独立性必然带来高昂的管理与维护成本。从工程角度而言，当拥有成千上万的服务时，集中式的管控平台并不像我们认为的那样糟糕，确保大部分团队能使用相同的方式、相同的标准，能够低成本运作。
五：团队的信任危机
作为服务的交付团队的负责人，你可能有必胜的信念。充满豪情壮志，愿意带领团队遵循各种最佳实践、完美的实现所负责的服务。但是，你永远无法保证，依赖的所有上下游团队，也能按照同样的标准实现服务。这是现实。而且，随着服务关系越复杂，依赖越多，出问题的几率越大，信任危机愈发明显。
