SOA
面向服务的体系结构(SOA)是一种软件设计风格，其中服务由应用程序组件通过网络上的通信协议提供给其他组件。
面向服务的体系结构的基本原则独立于供应商、产品和技术。
服务是一个独立的功能单元，可以远程访问、独立操作和更新，比如在线检索信用卡账单。
根据SOA的许多定义之一服务有四个属性
-
它逻辑上表示具有指定结果的业务活动。
-
它是自包含的。
-
对于消费者来说，这是一个黑盒子。
-
它可能包含其他基础服务。
可以同时使用不同的服务来提供大型软件应用程序的功能，这是它与模块化编程共享的原则。
面向服务的体系结构集成了分布式、独立维护和部署的软件组件。
它是通过技术和标准实现的，这些技术和标准使组件更容易通过网络进行通信和合作，特别是IP网络。
优点
松耦合
之前的所有操作集成于某个功能模块，包括数据操作、逻辑处理等等。当项目一旦大起来，可能一次操作要操作多个功能模块，那么这种嵌套关系就变得很复杂，导致相互依赖，那么之前所有的东西修改起来都会影响到其它业务的执行，这样维护起来变得相当困难。
而松耦合恰好就是解决这种依赖关系，通过接口访问数据信息。
不允许直接访问其它服务的数据，因为它破坏了封装性，造成了一种内部依赖。当服务的内部状态发生改变，则这改变带来的影响会散播到所有依赖该服务的地方 —— 做软件的人都知道，这是最头疼的事情，各种莫名的bug往往在这种情况下产生。
组件化
laravel的composer组件库、ruby的gem组件库、jquery组件库等等， 组件之所以为组件，是因为当下载或拉取之后，能够通过很简单的东西实现某一功能。
可复用
SOA架构是面向服务的架构设计，它通过封装一个服务，所有的操作数据功能，都只能用给定的接口使用。
当需要扩展一个功能时，如果已存在相应接口，那么只需要调取相应的接口即可。
跨平台/语言
Service层可以用任何语言来实现，也可以使用多种语言，实现物尽其用的原则，比如PHP擅长处理逻辑、Ruby语言擅长高并发、java大数据等。
但提供的接口统一，不管服务层如何实现，应用层只需要调用接口即可。
易上手
何为易上手？
当进入到一个公司，首先要做的是熟悉代码，少则四五天，多则七八天，因为嵌套太多，要屡清楚层层的关系。
而SOA架构呢，服务层跟应用层分离，刚进入公司，你直接可以写东西，接口数据唯一，你只需要了解都有啥接口，然后这些接口传递参数、返回的数据就可以了。
经验和教训
教训一：SOA架构的错误定位，非常麻烦。
一个请求可能要经过20次服务器调用，才能找到问题的真正所在。通常，单单是问题的定位就要花费15分钟到几个小时，除非搭建大量的外围监控和报警措施。
教训二：同事也是潜在的 DOS 攻击者。
公司内部某个小组，会突然对你的服务发起大量请求。除非每个服务都设有严格的用量和限量措施，否则根本无法保证可用性。
教训三：监控和质量保障（QA）是两回事。
监控一个服务的时候，可能会得到”一切正常”的回复。但是很有可能，整个服务唯一还正常工作的部分，就是这个回应”一切正常”的模块。只有完整地调用服务，才能确定服务是正常的。
这意味着，真正监控一个服务，必须做到对所有的服务和数据进行完整的语意检查，否则是看不出问题的。如果做到了这一点，本质上就是在做自动化 QA 了。
教训四：必须有服务发现机制。
面对成百上千的服务时，没有服务发现机制是不可想象的。这又离不开服务注册机制，而它本身也是一个服务。亚马逊有一套统一的服务注册机制，可以通过编程的方式找到所有服务，包括一个服务有哪些API，目前是不是运行正常，在什么位置等。
教训五：必须有沙箱用来调试
如果代码中调用了他人服务，查找问题的难度要高很多，除非有统一的方式在沙箱里运行所有服务，否则几乎不可能进行任何调试。
教训六：不能信任任何人
团队采用服务的方式进行合作以后，基本上就不能信任其他团队了，正如不能信任第三方工程师一样。
拓展阅读
参考资料
https://en.wikipedia.org/wiki/Service-oriented_architecture
