一种架构模式的出现不是为了取代以前的架构模式，而是为了更好的改进以往架构模式，也是适应一种环境，适应一种场景。
出现了微服务，并不是喜欢微服务，而是大势所趋，解决了一些问题，也带来了新问题，同理，人也是一样，没有一种方法，或者一个人是银弹，这就是自驱动的来源。
序言
1 复杂度
一个软件系统的诞生，中间充杂着无数的细节问题，也可以认为是中间有无数的坑等着你去踩，你踩或者不睬它都在那里。
软件系统，有逻辑复杂度，有各种人为因素的复杂度，逻辑复杂度主要是业务，业务本身复杂，业务持续增长之后带来的并发复杂，有人的技术水平的高低，有人的经验水平的高低，有各种环境，政策等的影响，一样因素没考虑到，就可能整体流产。
2 SOA与微服务适用的场景
SOA主要解决是各种异构系统的重复建设问题，异构就是指采用不同的语言，不同的架构，不同的协议，不同的数据结构进行开发的系统，有java有c++，有用json的，有用xml的，有用http的，有用rpc的，而重复建设，就是每个系统都要实现自己的一套鉴权系统，相互之间的调用通过重量级的ESB来实现，各种协议的转换，数据格式的转换。
微服务和SOA一样，都是根据服务来进行划分，相对来说，SOA模式是重量级的服务，可能一个服务里面可能会拆分成好几个微服务，故微服务更加轻量级。从而能更好的快速的迭代，加快系统的发展和迭代速度。
SOA和微服务各有存在的道理，看到新出来的技术，是否要进行系统改造和迁移？
SOA的服务如果进行改造，那么成本有多大？收益是否足够多？未来的服务是否会快速改变和发展？这几个是主要的衡量因素。
如果改造的成本很大，或者没有能力改造，例如发展了几十年的系统，没人敢动，但是业务很稳定，变化的部分也不多，那么改造的动力在哪儿，毫无意义。
进行改造或者优化，不是为了技术而技术，而是为了业务才改变技术，才推动技术，业务如果快速发展迭代，你不得不采用新的技术来解决这些问题，但是如果目前没有问题，无需改造，没有问题创造问题也要上？
业务才是关键。
3 分析
总体架构优缺点分析：SOA能通过ESB兼容各种异构系统，业务的发展改动不大，ESB成为性能瓶颈，服务治理的难度大；微服务能快速进行迭代，适应互联网节奏，但是基础服务成为关键，没有基础，会死的很难看。
两种架构模式都是为了可扩展性而生，只不过可扩展的角度不一样，SOA的可扩展是通过直接加一个应用系统，一个大的服务，而微服务则是提供很多小服务，从细节点来进行改动，从而更好的提高用户体验。
用户是小白鼠，好好体验。。。
微服务的发布部署都是自动化，而且在进行发布部署的时候，能自动进行服务容错，应用重连，支持各种蓝绿发布，灰度发布，从而对业务来说，基本上无感知。
SOA也可以是自动发布部署的，一般需要各个应用系统的配合，也有可能是跨部门配合，也能做到灰度发布。
现状分析，一般是针对目前存在的问题，从而针对的分析，需要一个实例来进行分析，例如SOA系统支持的并发最多100000，而未来的不能支持，从而必须对现有系统进行改造。。。不得以而为之。
每一种策略的引进都是为了解决某些目前策略无法解决的问题。
微服务突破了ESB的性能瓶颈，其实如果ESB做的好，也一样不会是性能瓶颈，而在微服务里面，你可以理解API网关是整个系统的瓶颈。。。一切取决于你的团队的实力。
新。。。并不意味着一切，你认为好的，可能也是不好的，你可以做的，其他的也可以做。。。新，意味着不成熟，意味着要试错，人生没有测试环境，都是生产环境，好好珍惜。
本文里面，你可能看不懂，不过没关系，你记住两句话就可以了。
1 复杂度或者问题不是消失了，而是转移了---就像我们说ESB是重量级的，其实微服务里面的基础设施部分，需要注册中心，需要自动部署，需要自动测试等各种系统，不是你真的把复杂度解决了，而是转移到了基础设施里面。---就像你学的很多东西，你可能忘记了，但是它们还在那里，只是它们变成了你的历史记忆---就像有人问，你爱过我吗？回答是爱过。。。
2 复杂度或者问题不是消失了，而是有积累了---就像ESB是重量级的，到了微服务里面你把他都变成基础设施了，每次都会用到，而对于你来说，你是无感知的。----就像父母给你的爱一样，不是消失了，而是在默默的关注着你的一切，只是。。。你是无感知的，等你积累到了一定的程度，最终。。。你还是有感知的，虽然延迟有点大，反射弧有点长。。。BASE算法，数据终将一致，只是取决了你的感知时间。
不怕无感知，就怕你不自治，自以为是。