SOA和微服务架构的区别
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。 如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。 把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述： 微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。 微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。 再强调下即： 首先对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键，即我们在进行单个应用组件设计的时候，本身在组件内部就会有很大接口的设计和定义，那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务，而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。 其次，微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说，组件超外部暴露的能力才需要发布为微服务，其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑，组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。 微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。 对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后，虽然整体架构可以松耦合和可扩展，但是如果拆分的组件越多，这些组件之间本身的集成和部署运维就越复杂。即任何一个组件，当他依赖的外部其它应用组件越多的时候，整个集成，部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量，一是增加出错概率。 原来谈组件化开发谈的最多的是单个组件的持续集成，包括配置环境集成，自动打包部署，自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成，其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路，希望能够实现开发设计到部署运维的一体化。 由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行，各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性，我们可以用虚拟机，但是当几十个进程都完全用独立的虚拟机就不现实的，而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情，每个Docker是独立的容器刚好又完全做到进程级别的隔离，资源占用率又最小，这些特点刚好满足微服务架构的开发测试和自动化部署。 前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台，按照当前微服务架构的整体思路，虽然单个服务的实现和发布仍然是在组件内部完成的，但是这些组件暴露的服务本身的调用情况，服务本身的安全，日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。 由于微服务尽量都是通过HTTP API的方式暴露出去的，因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册，服务代理，服务发布，服务简单的路由，安全访问和授权，服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构，即可以做为微服务架构下的服务管控平台。 对于这种服务管控平台，核心需要讨论的就是服务每次调用本身的消息传递，输入和输出日志是否需要记录，当前就有两种做法，一种是不记录，管理平台只负责服务注册和目录发布，安全授权，实际的服务访问仍然是两个组件之间的点对点连接完成，这种方式下整个架构下获取更高的性能，同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈；另外一种方式就是完全记录，在这种方式下就需要考虑服务管理平台本身的集群化不是，高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力，同时仅仅对核心的需要Log日志的服务进行日志记录，而其它服务只提供服务目录和访问控制即可。 ===========2016.6.8日更新，增加Chris Richardson微服务系列读书笔记 本文为阅读《Chris Richardson 微服务系列》的阅读笔记，具体原文参考：「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例 ，私信“555”有惊喜！！ 里面有另外四篇的链接，当前daocloud已经更新到第5篇事件驱动架构。 第一篇 微服务架构的优势和不足 文中强调的单体应用的场景，我在前面很多谈组件化和服务化的文章里面已经都谈到过了，即一个应用系统里面的模块没有办法做到彻底解耦，如果要实现按组件单独部署是不可能的，相互之间仍然有大量内部不可见依赖而导致了模块间无法拆分。 那么单体应用本身带来的问题主要有哪些？ 1.系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身。 2.运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。 3.无法扩展：无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是DB问题难解决 正是由于这些原因需要考虑引入微服务架构（实质仍然是单个应用本身的组件化和服务化），对于微服务文章里面有一个详细说明如下：一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种接口。有的微服务通过暴露API 被别的微服务或者应用客户端所用；有的微服务则通过网页 UI 实现。在运行时，每个实例通常是一个云虚拟机或者 Docker容器。 从这个定义和说明仍然需要做一些关键理解，即在我前面谈微服务的文章里面谈到过的，即核心的几点包括了，其一足够构成一个独立小应用（从DB到UI），其二微服务应用之间只能通过ServiceAPI进行交互，其三一般运行在云虚拟机或更轻的Docker容器上。 APIGateway，这实际上微服务架构里面的很重要的内容，其作用类似于传统企业内部的ESB服务总线，只是更加轻量和高性能来解决微服务的管控和治理问题。而对于负载均衡，缓存，路由，访问控制，服务代理，监控，日志等都属于基本的服务管控内容，也是APIGateway需要考虑的核心能力。 Scale Cube的3D模型，描述的相当好，即通过微服务架构实施后扩展性的变化。 1. Y轴：本质是应用的分解，即将传统的单体应用分解为多个微服务应用。 2. X轴：水平弹性扩展能力，即通过负载均衡来实现水平弹性扩展，但是DB问题无法解决，引入3 3. Z轴：当单个微服务应用引入了DB弹性扩展能力要解决的时候，我们引入了对数据库进行拆分和DaaS 对于微服务架构的好处前面在讲单体应用的问题的时候已经谈到了，微服务架构正好是解决这些问题。而对于微服务架构的不足，简单总结如下： 1. CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题。 2. 集成复杂：任何彻底的分解都将带来集成的复杂度，即模块在集成时候需要外部微服务模块更多的配合。 …