微服务架构演变

随着业务量的增加，应用规模的扩大逐渐演变到微服务，根据项目需求、特点选择应用架构

单体架构：垂直式，所有的一切是在一个项目中完成，一个war包，项目中有分层的思想，但是物理层面上来讲是一个整体，有点：开发迅速，但是耦合度非常高，因为随着业务量的增大，项目规模的扩大，如果需要更改某个业务controller，或者服务层，那么整个war包都需要重新发布

分布式架构
RPC架构：按照不同的业务将垂直架构分开，在物理上将控制，页面与数据、服务分开，服务层可以被多个web层公用，提高代码复用性
web调用服务层是通过网络，IP和端口，比如进程1调用4,5，需要自己本身维护服务4,5地址.那么，如果想实现服务提供者的集群搭建，实现分流，负载均衡，比如，复制一个服务4出来，那么对于web来说第一次调用4.1，第二次调用4.2，无形当中增大了web层的调用压力
优化
面向服务的架构20、30
SOA服务化架构：将服务提供者的网络地址注册到注册中心，那么web层在调用时在注册中心找某一个服务的网络地址，拿到后进行网络调用，优点：就算服务地址变更，那么调用者web层不用更改，并且可以基于服务中心实现负载均衡：比如有两个服务4，他们是两个相同的节点，服务名称相同，IP不同，现在两个4都把地址注册进注册中心，那么服务的调用者在上层根据名称调用时，注册中心根据服务名称返回服务地址，那调用者不用管需要调用哪个，注册中心返回那个地址就调用哪个，因为对于调用者和提供者来讲，只需要关心自身的提供和调用就可以，不用去关心负载均衡，而且也可以在项目运行之后
，实时的通过服务治理中间件，观察当前提供者和调用者的运行状态，考虑要不要增加提供者的节点，降低耦合，松耦合

微服务架构：服务化的架构风格，能很好地实现独立开发，百人团队
将不同的功能拆分成一个个小的应用，那么搭建集群时根据服务压力大小来搭建，可以选择性的组合，每一个微服务包含3层，每一个都是一个单体架构，
每一个功能按照业务拆分，极大地降低了耦合度，独立开发，独立上线，用RESTFOR：HTTP+JSON风格实现相互之间的调用，web层有SpringMVC，访问的话返回JSON，只要知道另一个微服务的地址就可以实现调用，那么考虑到地址变更问题，微服务之间存在接口
提供每一个服务的接口，接口确定之后基本不会变更，那么对于调用者来讲只需要面对接口（访问地址）调用就行，
目的：解耦，逻辑上是整体，相互之间存在关系
DevOps:工具站，给运维和开发提供的工具站，在进行技术选型时就比较统一