最近学习了SOA和微服务概念

由于最近要学习微服务，首选的实践就是springcloud，但是仔细回顾以往做的项目也逃不出springmvc模式，其中可能有一部分的功能被提取出单独模块，也算是归为SOA模式 服务模块划分，内部通过restful API HTTP调用 ，这些和微服务没毛钱关系，从宏观上对微服务架构设计有一个初步的了解

1、单体架构

2、单体架构的拆分

3、SOA与微服务

4、微服务的优缺点

5、微服务的消息

6、服务集成

7、服务发现

8、服务注册

9、数据的去中心化

 

SOA：是按水平架构划分为：前、后端、数据库、测试等，提soa必须提到的ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务， 做了消息的转化解释和路由工作，让不同的服务互联互通；

SOA体系下，服务之间通过企业服务总线（Enterprise Service Bus）通信，许多业务逻辑在中间层（消息的路由、转换和组织）。微服务架构倾向于降低中心消息总线（类似于ESB）的依赖，将业务逻辑分布在每个具体的服务终端。

微服务：其实和 SOA 架构类似,微服务是在 SOA 上做的升华，剔除SOA中复杂的ESB企业服务总线采用API网关，强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品；API网关方式应该是微服务架构中应用最广泛的设计模式。

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

SOA将组件以library的方式和应用部署在同一个进程中运行，微服务则是各个服务独立运行。权限服务A 与支付服务B ，在B 提交支付时 如果需要验证user权限,只能通过A暴露的接口获取；不能直接管理表去搞，每个服务都可以单独一个库或者跨数据源的库， 但是需要注意的时 ，可能徒增接口数量，增加工作量

• 尽可能把接口设置成粗粒度，每个服务方法代表一个独立的功能，而不是某个功能的步骤。否则就会涉及到分布式事务

SOA架构特点：有序 复用 高效

系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

 

参考文献： 

http://www.uml.org.cn/zjjs/201708083.asp

https://zhidao.baidu.com/question/1899225333752310100.html

http://blog.sina.com.cn/s/blog_493a84550102wq50.html
————————————————
版权声明：本文为CSDN博主「zpoison」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zpoison/article/details/80729052