atititi.soa 微服务 区别 联系 优缺点.doc
4.1. 通过服务实现组件化 vs 通过库（library）3
5. 服务划分有两个原则要遵循：单一职责原则 每个工具都小而美4
1. 应用微服务的动机，跟传统巨石应用的比较
web应用程序发展的早期，大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。其他语言(Ruby，Python或者C++)写的程序也有类似的问题。
假设你正在构建一个在线商店系统：客户下订单、核对清单和信用卡额度，并将货物运输给客户。很快，你们团队一定能构造出如下图所示的系统。
这种将所有功能都部署在一个web容器中运行的系统就叫做巨石型应用。巨石型应用有很多好处：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。
但是，上述的好处是有条件的：应用不那么复杂。对于大规模的复杂应用，巨石型应用会显得特别笨重：要修改一个地方就要将整个应用全部部署(PS：在不同的场景下优势也变成了劣势);编译时间过长;回归测试周期过长;开发效率降低等。另外，巨石应用不利于更新技术框架，除非你愿意将系统全部重写(代价太高你愿意老板也不愿意)。
作者:: 绰号:老哇的爪子 （ 全名：：Attilax Akbar Al Rapanui 阿提拉克斯 阿克巴 阿尔 拉帕努伊 ） 汉字名：艾龙， EMAIL:1466519819@qq.com
转载请注明来源： http://blog.csdn.net/attilax
2. 面向服务架构（SOA） esb
面向服务架构 SOA 思想概念的提出已不是什么新鲜事，大概在10年前就有不少相关书籍介绍过。当时 java 企业应用领域 J2EE 依然是主流，应用程序被部署在庞大统一的符合 J2EE 规范的容器中运行，在单一进程中提供所有的功能。 而 SOA 提出的一些架构原则，在当时看来无疑是革命性的。 由于业已存在的大量单一庞大的应用，按照 SOA 的思想和架构原则来改造无疑相当于推翻重新开发一遍，在成本上很难接受。 因此早期的 SOA 通常和另外一个术语关联在一起——ESB（企业服务总线）。 当时在 SOA 的实施思路上无一例外的选择了 ESB 模式来整合集成大量单一庞大的应用，以保护企业前期投入成本。因此 ESB 其实是 SOA 特定历史阶段的一种实现方式。
3. 微服务架构（Microservices）
对微服务架构我们没有一个明确的定义，但简单来说微服务架构是：
采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。
4. 微服务架构特征（Characteristics）
4.1. 通过服务实现组件化 vs 通过库（library）
传统实现组件的方式是通过库（library），传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。 另外将服务作为组件可以更明确的定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。
微服务哲学还给企业提供了框架，用于思考如何拆分应用，以一种可扩展成不同部分的应用形式。其中一个较好的方法是把应用拆分成独立的容器，使用内部应用相互通信，而不是使用传统的SOA进行内部应用通信，Anuff说。
有了微服务，电脑的最小单元就是最小的Docker容器，10行的node.js代码
4.2. 去中心统一化 vs 统一的技术平台
传统应用中倾向采用统一的技术平台或产品来解决所有问题。 不是每个问题都是钉子，也不是每个解决方案都是一个锤子。 问题有其具体性，解决方案也应有其针对性。 用最适合的技术方案去解决具体的问题，在大一统的传统应用中其实很难做到，而微服务的架构意味着，你可以针对不同的业务服务特征选择不同的技术平台或产品，有针对性的解决具体的业务问题。
4.3. 7. Design for failure
正因为将服务独立在不同的进程中后，引入了额外的失败因素。 任何时刻对服务的调用都可能因为服务方不可用导致失败，这就要求服务的消费方需要优雅的处理此类错误。 这其实是相对传统应用开发方式的一个缺点，不过随着一些开源服务化框架的出现，对业务开发人员而言适当的屏蔽了类似的错误处理，不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的
5. 服务划分有两个原则要遵循：单一职责原则 每个工具都小而美
(1)每个服务应该尽可能符合单一职责原则——Single Responsible Principle，即每个服务只做一件事，并把这件事做好;(
(2)2)参考Unix命令行工具的设计，Unix提供了大量的简单易用的工具，例如grep、cat和find。每个工具都小而美。
6. 比较soa
微服务架构和SOA是不一样的。但高层次的想法源于对庞大应用程序的沮丧。Martin Fowler在一片文章中的解释比这个全面得多。把你的应用程序作为服务套件，而不是一个紧密耦合整体的代码来创建时，更容易修改和维护——特别是需要全天候运行的Internet应用程序。只要重构和重新部署几个服务，并不需要重装并重新释放整体
6.1. 相似却不相同
微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。但是两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
总结：
|
功能 |
SOA |
微服务 |
|
组件大小 |
大块业务逻辑 |
单独任务或小块业务逻辑 |
|
耦合 |
通常松耦合 |
总是松耦合 |
|
公司架构 |
任何类型 |
小型、专注于功能交叉的团队 |
|
管理 |
着重中央管理 |
着重分散管理 |
|
目标 |
确保应用能够交互操作 |
执行新功能，快速拓展开发团队 |
7. 案例:shop
按照功能和资源划分后，就形成下面图3的架构图。分解后的微服务架构包含多个前端服务和后端服务。前端服务包括Catalog UI(用于商品搜索和浏览)、Checkout UI(用于实现购物车和下单操作);后端服务包括一些业务逻辑模块，我们将在巨石应用中的每个服务模块重构为一个单独的服务。
服务。这么做有什么问题呢?
8. 微服务架构的关键问题
8.1. 1. 微服务架构的通信机制
(1)客户端与服务器之间的通信
，客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上无线网络的延迟高，会严重影响客户端的用户体验。
为了解决这个问题，一般会在服务器集群前面再加一个角色：API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。这样做还有个好处是，服务升级不会影响到客户端，只需要修改 API gateway即可。加了API gateway之后的系统架构图如图5所示。
(2)内部服务之间的通信
内部服务之间的通信方式有两种：基于HTTP协议的同步机制(REST、RPC);基于消息队列的异步消息处理机制(AMQP-based message broker)。
8.2. 2. 分布式数据管理
(1)处理读请求
(2)处理更新请求
当一份数据位于多个服务上时，必须保证数据的一致性。
分布式事务(Distributed transactions)使用分布式事务非常直观，即要更新Customer Service上的信用卡额度，就必须同时更新其他服务上的副本，这些操作要么全做要么全不做
9. 重构巨石型应用
在实际工作中，很少有机会参与一个全新的项目，需要处理的差不多都是存在这样那样问题的复杂、大型应用。这时候如何在维护老服务的同时，将系统渐渐重构为微服务架构呢?
不要让事情更坏，有新的需求过来时，如果可以独立开发为一个服务，就单独开发，然后为老服务和新服务直接编写胶水代码(Glue Code)——这个过程不容易，但这是分解巨型服务的第一步，如图7所示;
识别巨石型应用中的可以分离出来当做单独服务的模块，一般适合分离的模块具有如下特点：两个模块对资源的需求是冲突的(一个是CPU密集型、一个是IO密集型);授权鉴定层也适合单独分离出一个服务。每分离出一个服务，就需要编写对应的胶水代码来与剩下的服务通信，这样，在逐渐演进过程中，就完成了整个系统的架构更新。
10. 参考
微服务与SOA之间差了一个ESB(2) - 51CTO.COM.htm
面向服务与微服务架构 - 瞬息之间 - 博客频道 - CSDN.NET.htm
微服务（Microservice）那点事 - 开源中国社区.htm