面向服务架构
面向服务架构的思想在整个软件的架构中已经不是什么新鲜的东西。我简单地认为服务化是模块化的延伸，所以服务化有着和模块化类似的优点和缺点。无论你采用哪种协议定义服务与服务之间的通信方式(如WebServices.私有协议等)，这并不是服务化的本质所在，即使Java语言用RMI进行服务与服务之间的通信也仍然不违背服务化的宗旨。
为什么需要面向服务架构
1.我觉得面向服务的根本好处是便于管理，也是应用大到一定时候的必然产物。这往往和组织架构之间相契合。其实不合理的服务划分也会带来服务之间的混乱。
2. 面向服务是一个解耦的过程，松耦合降低了服务之间的依赖，也意味着服务一个服务出现故障的时候不容易引起连锁反应，也能更好的控制服务与服务之间的关系与优先级。
3.不同语言之间的通信。
SOA
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、 松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML (标准通用标记语言的子集)/Web Service 技术之后的自然延伸。SOA将能够帮助软件工程师们站在一 个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
传统的Web (HTMLHTTP)技术有效地解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务(XMLSOAP/WSDL)技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAICB2C的发展。SOA (面向服务的体系)则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑(business logic)或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。
SOA具有的特性
SOA服务具有平台独立的自我描述XML文档。Web服务描述语言(WSDL, Web ServicesDescription Language)是用于描述服务的标准语言。
SOA服务用消息进行通信，该消息通常使用XML Schema来定义(也叫作XSD, XML SchemaDefinition)。.消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部, SOA服务通过一 个扮演目录列表( drectory listing)角色的登记处( Regitry)来进行维护。应用程序在登记处(Registry)寻找并调用某项服务。统一描述， 定义和集成(UDDI，Universal Description, Definition, and Integration)是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质(QoS, quality of servce). QoS的一些关键元素有安全需求(例如认证和授权)，可靠通信(可靠消息是指，确保消息仅发送一次， 从而过滤重复信息。)，以及谁能调用服务的策略。
SOA三大基本特征
1)独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Intermet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术如.NET Remoting, EJB， COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其他功能部分出现问题的时候，在该宿主上运行的其他应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction),消息队列(Message Queue),冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。
2)大数据量低频率访问
对于.NET Remoting, EJB 或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet 环境下这些因素往往是决定整个系统是否能正常工作的一一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。
3)基于文本的消息传递
由于Intemet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能;但是在Internet 环境下，不同语言，不同平台对数据、甚至是-一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。
此外，对于一个服务来说，Intermet 与局域网最大的一个区别就是在Intemet. 上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其他的数据，从而得到的非常理想的兼容性。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
微服务架构( Microservices )
对微服务架构我们没有一个明确的定义，但简单来说微服务架构是采用一组服务 的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻 量级交互机制来通信,例如RPC、HTTP等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。
微服务架构特征(Charateristics) 包括如下这些特点:
1)通过服务实现组件化
传统实现组件的方式是通过库(library), 传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。另外将服务作为组件可以更明确地定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。
2)按业务能力来划分服务与组织团队
康威定律(Conway's law)指出，任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。
传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为UI、页面构建师等，中间层对应的角色为服务端业务开发工程师，数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反映了不同角色的沟通结构。而 微服务架构的开发模式不同于传统方式，它将应用按业务能力来划分为不同的服务，每个服务都要求在对应业务领域的全栈(从前端到后端)软件实现，从界面到数据存储到外部沟通协作等。 因此团队的组织是跨功能的，包含实现业务所需的全面的技能。近年 兴起的全栈工程师正是因为架构和开发模式的转变而出现，当然具备全栈的工程师其实很少，但将不同领域的工程师组织为一一个全栈的团队就容易得多。
3)服务即产品
传统的应用开发都是基于项目模式的，开发团队根据- -堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。而微服务架构的倡导者提议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点:
开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者(客户)形成每天的交流反馈，来自直接客户端的反馈有助于开发者提升服务的质量。
4)智能终端与哑管道
微服务架构抛弃了ESB过度复杂的业务规则编排、消息路由等。 服务作为智能终端，所有的业务智能逻辑在服务内部处理，而服务间的通信尽可能的轻量化，不添加任何额外的业务规则。
5)去中心统一化
传统应用中倾向采用统一 的技术平台或产品来解决所有问题。不是每个问题都是钉子， 也不是每个解决方案都是一个锤子。 问题有其具体性，解决方案也应有其针对性。用最适合的技术方案去解决具体的问题，在大一-统的传统应用中其实很难做到，而微服务的架构意味着，你可以针对不同的业务服务特征选择不同的技术平台或产品，有针对性的解决具体的业务问题。
6)基础设施自动化
单一进程的传统应用被拆分为一 系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。必须要有 合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。
7) Design for failure
正因为将服务独立在不同的进程中后，引入了额外的失败因素。 任何时刻对服务的调用都可能因为服务方不可用导致失败，这就要求服务的消费方需要优雅的处理此类错误。这其实是相对传统应用开发方式的一一个缺点，不过随着一些开源服 务化框架的出现，对业务开发人员而言适当的屏蔽了类似的错误处理，不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的。
8)进化设计
一旦采用了微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务契约(接口)的兼容性。对于解耦服务消费方和服务提供方，伯斯塔尔法则(Postel's law)特别适用，即发送时要保守，接收时要开放。
按照伯斯塔尔法则的思想来设计实现服务调用时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍信息的兼容性。多 余的信息不认识可以忽略，而不应该拒绝或抛出错误。
微服务架构应用
采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多 个服务。有一个一般的原则是，单一服务提供的功能是可以独立被替换和升级的。也就是说如果有A和B两个功能，如果A功能发生变化时同时B功能也需要变化,那么A和B这两个功能应该被划在一个服务中。
微服务架构应用的成功经验近年已越来越多，例如国外的Amazon, Netflix, 国内如阿里都采用微服务架构取得了很多正面的成功案例。但通过 上文所述微服务架构特征看出，其实微服务架构模式有利有弊，需要根据实际的业务、团队、环境进行仔细权衡利弊。其中 的服务拆分带来的额外开发、测试、运维、监控的复杂度，在现有的环境、团队下是否能够很好的支持。
另外，有人可能会说，我一开始不采用微服务架构方式，而是在单一进程内 基于清晰定义的模块化方式，模块之间通过接口调用，到了适当阶段，必要的时候再将模块拆分为服务。其实这个想法显得过于理想，因为进程内良好定义的接口通常不是很好的服务化接口。一 开始没有考虑服务化的设计方法，那么后期拆分时依然是一个痛苦的过程。
总的来说，面向服务架构是一种思想，当然对于大系统而言其利必大于弊，而系统比较小的时候盲目的拆分和服务化其实会导致整个维护成本上升。系统架构并没有一成不变的套路，也不必完全遵循某种模式。一切都在实际应用中结合具体的应用场景。应该说是“方法论”的具体产物。