这是我的第一篇博客，写的是关于自己对微服务以及cloud的一些认识。
1.应用架构发展史
微服务一次很早就提出来了，一直不明白微服务是干嘛的，相信许多和我一样的这种小白一样吧。直入主题，先说下应用架构的发家史吧，目前的软件架构有三种类型类型，分别是业务架构、应用架构、技术架构、他们之间的关系是业务架构决定应用架构，技术架构支撑应用架构。架构的发张历程是从单体架构、分布式架构、SOA架构再到微服务架构，如图
1.1单体应用架构
单体应用架构可以理解为一个javaweb应用程序，包含表现层，业务层、数据层，就是我们平常说的MVC模式，从controller到service再到Dao层,“一竿子捅到底”，没有任何拆分，开发完以后就变成一个超级大的war包进行部署；
单体架构的优点：
易于开发：开发人员使用当前的开发工具在较短的时间内就可以开发出具体的单体应用
易于测试：因为不需要依赖接口，都在一个项目中，所以可以节约许多时间。
易于部署：开发完成后直接war包，部署在安装jre的环境中即可。
单体架构的缺点：
灵活性不够：如果程序有任何修改，修改的不是一个点，而是从上到下去修改，测试的时候必须要等到整个程序部署完之后才能看出效果，在开发过程中可能存在必须要等其他开发开发人员开发完相应的功能才能继续开发，降低了开发团队的灵活性，浪费开发时间。
降低系统的性能：原本可以直接访问数据库的，现在多了一层，即使只包含一个功能点，也必须在各个层上写对应的代码。
系统启动慢：一个进程包含了所有的业务逻辑，涉及的启动的模块过多，导致系统的启动时间延长。
系统扩展性差：增加新东西时。不能针对单个点加，而是对全局的增加，牵一发而动全身。
系统运行的风险较高：单体架构的服务在某个点出现异常宕机时，会造成整个系统宕机。
1.2、分布式
传统的分布式就是按照业务垂直切分，每个应用都是一个单体架构，通过api进行互相调用，实现业务的交互
简单的讲就是，可以把每个模块或者相关一类服务的作为一个服务，各个系统按照不同的业务切割将单体架构系统切割成多个不同的服务系统，这些系统之间通过接口互相调用，实现业务需求
1.3、面向服务的SOA架构
面向服务的架构是一种软件体系结构，其应用程序的不同组件通过网络的通信协议向其他组件提供服务或消费服务，所以其实说白了也是一种分布式架构，简单的来讲，SOA是不同业务建立不同的服务，服务之间的 数据交互粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务变的可组合。
1.4 微服务架构
目前比较世面上比较知名的微服务框架有spring cloud和阿里的Dubbo，为服务框架本人理解的其实就是一句话总结为一句话，“一切皆服务”，大家应该知道java有句话叫 “一切皆对象”，其实微服务就是可以把所有的功能都看作一个单独的为服务颗粒，自己运行自己的，是对SOA以及分布式的进一步升级，相当于服务粒度更小了，独立的服务之间是松耦合的，通过远程通信就可进行交互，各服务之间均可被独立部署、扩容。
简单说下Dubbo和cloud的区别：Dubbo其实更偏向于RPC领域，成为微服务的一个组件，Dubbo正在积极适配开源方案，比如最近宣布的Nacos，nacos的定位是一个更易于帮助构建原生应用的动态服务发现、配置和服务管理平台。一次基于Dubbo的微服务解决方案是：Dubbo+Nacos+其他。
springcloud则是一个比较全面的微服务框架，通信方式：REST/Http，服务发现/注册:Eureka(Ap),负载均衡：Ribbon，容错机制：6种容错机制，Hystrix熔断机制，cloudConfig配置中心，网管：zuul/Gateway,服务监控：Hystrix+Turbine，链路监控：Sleuth+Zipkin，Rest支持多语言。
总结：其实目前springCloud市场上还是不太活跃，一来，为维护成本大，维护的难度较高，二者，大部分稍微大点的项目才会用到微服务框架，一般的项目都会选择单体架构，毕竟容易开发，也容易开发，这是本人的对框架的一些浅见，虚心接受批评和探讨