SOA简介
SOA（Service-Oriented Architecture，面向服务架构）是一种将信息系统模块化为服务的架构风格。拥有了服务之后，我们就可以迅速地将这些服务按不同方式重新组合，从而实现新的或更好的业务流程。
SOA跟传统的单体应用相比，其新颖之处在于我们可以更灵活的为服务提供者与消费者选择实现技术和部署位置。只要服务接口保持稳定，抽象出来的接口就能让提供者和消费者独立演变。这种稳定性向服务消费者隔离了服务实现的变化，缩小了每次因提供者改变而必须进行变更的工作范围，而这种工作范围的缩小以成本规避的形式带来了相应成本的降低。
服务
什么是服务？一个服务是供一个组件执行的定义良好的工作单元，并包装成易于被访问的格式。我的观点是，只把一个功能实现一次，并把它彻底的做好，然后它就可以被广泛的访问。
开发过程
SOA开发过程跟传统的单体应用开发过程有所区别，传统的单体应用一般的开发过程为：需求—>开发—>质量保证—>上线。而SOA需要在开发之前就有一个明确的架构定义步骤，该步骤从业务流程和系统架构两个方面确定了必须完成的工作，并给出各服务接口的详细定义，明确各服务的结构和职责以及将部署的物理环境。在开发完成之后还需要加入集成测试步骤，该步骤按架构定义时设计的次序装配服务，通过这个方法，一部分服务会先被装配和测试以确保它们能正确的交互；在证实这点之后，再增加更多的组件再次测试，直到装配整个系统，确保整个系统可用。完整的开发过程为：需求—>架构定义—>开发—>集成测试—>质量保证—>上线。
传统企业架构到 SOA 架构的迁移
将系统实施分成 3 个子策略：
新建组件(系统) ，当业务建模后发现现有系统均不能覆盖需求时，则必须新建一个组件(系统)以满足业务需求，新建的系统必须符合 SOA 架构规范标准
先改造组件(系统)后再重构 ，当业务建模后，发现某些原有系统基本功能可以满足业务需求时，但是不能满足 SOA 架构规范时，将原有系统进行 SOA 服务改造，使其能够符合新的 SOA 架构标准规范，待时机成熟时再重构成新的符合 SOA 架构要求的组件(系统)
保持现状 ，当此系统可以完全满足业务建模需求，而且 SOA 架构改造不够紧迫时，建议保持现状的系统。
按照上面的 3 个子策略特征，将现有系统进行全面分析，分别选择上述的 3 种实施策略，跟据业务需求的紧迫度、功能满足度、数据满足度、系统老化程度、资源投入状况、改造风险等维度，进行多轮迭代改造，逐步将企业中的全部系统改造成复SOA 架构。
这种多轮迭代的方式，可以充分的锻炼 IT 队伍，使大家的 SOA 架构能力逐步提高，每次迭代都使得标准、规范和管控逐步提高到新的成熟度，既满足了业务战略需求，又降低了实施风险和投入，是大型传统企业架构到 SOA 架构的一个较好的迁移策略。
故障处理
完善的日志与告警机制能够让我们在面对故障时收集到有用的信息，并及时处理。
容错与高可用
容错：我的理解是一个业务流程中有某个参与者失效，系统仍能继续提供正确服务而不中断。要实现这点，意味着同一服务至少要有两个提供者：只有有一个提供者失效，另外一个就会立即接手它的工作，继续提供服务，也就是所谓的故障转移。其中涉及的操作流程包括：检测主提供者已经失效—>激活后备提供者—>切换服务用户使用新的提供者。事实上容错性和高可用性通常都会使用这个方法。两者的区别在于：故障转移发生时所花费的时间和转移过程中的工作进展是否丢失。对于容错性而言，故障转移发生在提供服务的集群内部，转移切换的时间往往较短，且没有工作进展的丢失。
失效检测策略
很遗憾，参与者的失效几乎不可能被清晰的观察到。问题在于，观察本身也会失败。一种检测服务失效的简单方法一般是让服务提供心跳，在某个时间周期内，心跳消失即被解释为服务遇到问题。在这种设计下，需要处理随之而来的乒乓效应（The Ping-Pong Effect，也称为裂脑综合症（Split-Brain Syndrome））与脑死亡失效（Brain-Dead Failures）。乒乓效应：一旦网络出现过载，监视器将收不到心跳，从而判断主服务失效，结果，就算主服务实际仍在运行，后备服务还是会被激活并开始执行主服务的功能，这将导致两个一样的结果或顺序紊乱的结果，而当网络过载结束，心跳再次出现，其中一个组件将会回到后备角色，不幸的是，到这个时候，危害已经发生了。这种“启用-停用（Activation-Deactivation）”现象被称为乒乓效应（The Ping-Pong Effect，也称为裂脑综合症（Split-Brain Syndrome））。一个较好的解决方案是为心跳提供专用的网络。脑死亡失效：心跳策略假定服务失效必然导致心跳丢失，虽然完全失效的服务肯定导致心跳丢失，但在一个包含多线程的进程中，心跳的存在与否并不一定精确代表了服务的健康状况。如果心跳是由一个线程产生的，而服务的其他线程都已经处于阻塞或挂起状态，那么这个服务仍然产生心跳，即便此时它已无法正常工作。因此，为了确保心跳能精确的反映服务的健康状态，必须特别注意服务本身的设计（尽量保证主线程不被阻塞或挂起）。
故障转移管控
故障转移需要一个管理器——它用来判断是否需要故障转移并发起实际的故障转移过程，这个组件可以是后备服务自身（见我写的C10K开发框架一文，这篇文章我后续补充），也可以是一个独立的第三方组件，如Keepalived、Heartbeat等等。
无状态和有状态的故障转移
无状态组件：执行无状态原子操作的组件。其内部每个操作的每次调用都与其他调用完全独立，这些操作既不使用引用数据，也不保存数据，仅仅接收一个输入并返回一个输出。
有状态组件：组件执行保存信息的操作，这个信息会在随后的操作调用中被使用。
无状态的故障转移相对简单，只需完成以下三步即可：
1、检测到组件失效；
2、使后备组件联机；
3、把客户端重定向到后备组件。
有状态的故障转移需要一种机制：后备组件可以通过这种机制来了解主组件在故障发生时刻所处的状态。有两种基本技术可以用于这个目的。一种技术是，通过让后备组件主动监视主组件来使其保持最新状态，也就是通常所说的热备份（hot standby），另一种技术则是以一种可靠方式来保存活动组件的状态（通常是在磁盘上），并让后备组件可以在主组件失效时方便地对其进行检索。这种备份方式通常称为温备份（warm standby），它还有一个变种：后备组件无需保持已运行状态。在这种情况下，后备组件只有在启动后才能检索状态并接手工作，这种备份方式通常称为冷备份（cold standby）。
由于需要主动监视，热备份往往比较复杂，以致这种容错性监视方式在实践中极少实现——除了以容错方式持久化信息的存储组件。另一种状态共享方法是温（或冷）备份。在这种方法中，主组件以容错方式把需要共享的状态信息保存了起来，后备组件在故障转移过程中读取这个被保存的状态，然后恢复工作。这种备份虽然简化了后备组件的切换工作，但是却将问题的困难部分推给了持久化存储。要使持久化存储具备容错性并没有什么魔法，归根结底还是要复制信息（生成副本）并判断主副本崩溃的时机。一旦主副本崩溃，信息就从备份副本中恢复。
存储复制
存储子系统可以用两种信息复制方法：一种用来处理组件内部失效；另一种用来处理组件的完全失效，并故障转移到后备组件。后备组件可能位于同一数据中心（通常是数据中心内的另一防火隔离带）或另一个物理站点。组件内的信息复制通常使用RAID实现。组件间的信息复制一般采用异步事务日志复制实现。然而，根据CAP理论，数据的一致性、可用性与分区容错性无法同时实现，在实践中，往往需要牺牲一定的数据一致性，保证数据的最终一致性来妥协。要做到这点，需要在程序设计阶段就根据容许的数据丢失和故障转移时间对信息进行分类，以这个分类为基础，可以根据各个服务管理的信息和它们的底层技术，定义出它们各自的故障转移模式。
架构评估
架构评估的目的在于，在着手进行设计之前，先判断架构是否适用。用意正是为了确保演变中的架构始终符合要求。就一般的分布式信息系统而言，特别是面向服务的架构，一般至少要执行以下评估：
1、易用性：架构能否轻易实现它的预期目标；
2、性能：关键业务流程需求量分析，CPU、消息传递速率、磁盘、网络以及数据库性能；
3、成本和进度的可行性；
4、可观察性：监控，日志，故障检测与转移；
5、演变能力；
6、应对压力情况的能力。