然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高；另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据 。SOA 架构为了解决上面的问题，SOA 出现了 。SOA 代表了面向服务的架构，SOA 将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来；每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的；SOA 架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性 。
SOA 架构时代有两个很重要技术实现方式：Web Service 和 ESB ：前者提供了标准的数据传输协议，后者实现了服务编排和协议转换 。微服务架构但是随着用户和数据量的进一步增长，SOA 也暴露出来一些缺点，比如 SOAP 协议、XML较重；服务管理不完善；ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险 。
在微服务的架构中，各个微服务可以独立开发，独立部署；微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；每个团队的技术栈也可以不相同，只要遵守接口协议即可 。
至于微服务和 SOA 架构的区别，我是这样理解的：SOA 架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题；SOA 是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活 。
系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
下面简单回答下这个问题 。在回答这个问题前还是先回顾下微服务架构 。微服务架构概述微服务架构本质是单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同 。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用 。
微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号 。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想 。我们可以先看下从单体应用到微服务架构的变化图 。
把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通” 。关键在于该服务可以在自己的程序中运行 。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来 。在服务公开中，许多服务都可以被内部独立进程所限制 。
如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围 。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程 。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源 。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确 。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价 。
推荐阅读
- r530，三星笔记本R530给出参数懂的给个报价
- 开启跨境电商必备了解的知识点 跨境电商必备知识
- 黄色绶带是什么学位
- 远程能抹除掉什么数据
- 我要当小白鼠了！
- 黑色坚果
- 苹果x黑屏怎么强制重启，ipad进入dfu出不来了 强行关机没用 小雨伞也没用
- 苹果官网教育商店首页，在apple教育商店买了ipad付款后一直显示订单处理中也没有发邮
- 小狗为什么喝了吃了就吐怎么回事,狗狗吃多了呕吐怎么办
- 猫和狗为什么打架,家中养了猫和狗