从web层架构的演进了解微服务的概念，进而对微服务的组件有一定的了解；
从而知道为什么需要这些组件，以及这些组件设计的初衷，了解组件的责任和边界
单体架构
最早的时候，带宽所限，一个tomcat就可以搞定一个网站或者项目；MVC架构非常流行
即使在现在一些简单的网站和项目也可以使用nginx + tomcat；因为这样开发和维护成本比较低；
单体架构--面临的挑战
代码不断膨胀、功能越来越复杂、代码修改牵一发而动全身
访问量增加、软件和硬件都面临挑战、雪崩效应
重复代码增多，重复造轮子、测试变的复杂
- 复杂应用的开发维护成本变高、部署效率变低
集中式架构SOA
SOA架构一度也非常流行，能解决我们在单体架构中存在的问题。可以看到企业总线类似于服务网关的作用。
特点：
1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各系统提供服务。
2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。
3、ESB企业服务总线作为项目与服务之间通信的桥梁。
优点：
1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
2、可以针对不同服务的特点制定集群及优化方案。
3、采用ESB减少系统中的接口耦合。
缺点：
1、系统与服务的界限模糊，不利于开发及维护。
2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
3、抽取的服务的粒度过大，系统与服务之间耦合性高
集中式架构SOA-面临的挑战
SOA架构解决了应用服务化的问题、随着服务化的越来越深入、服务规模越来越大、服务治理面临的挑战也越来越多
- 服务框架如何支持线性扩展
- 分布式框架下的服务调用性能
- 如何查看日志，快速定位和解决故障
- 服务限流、重试、超时控制、服务失败策略
- 如何实现分布式服务监控
微服务架构
微服务架构的特点
微服务架构实现—阿里Dubbo
注册中心（registry）：生产者在此注册并发布内容，消费者在此订阅并接收发布的内容。
消费者（consumer）：客户端，从注册中心获取到方法，可以调用生产者中的方法。
生产者（provider）：服务端，生产内容，生产前需要依赖容器（先启动容器）。
容器（container）：生产者在启动执行的时候，必须依赖容器才能正常启动（默认依赖的是spring容器）
监控中心（monitor）：是dubbo提供的一个jar工程。主要功能是监控服务端和消费端的使用数据。
如：服务端是什么，有多少接口，多少方法，调用次数，压力信息等，客户端有多少，调用过哪些服务端，调用了多少次等。
微服务架构实现—SpringCloud
基本步骤
1、启动服务将服务注册到注册中心
2、启动服务网关注册到注册中心
3、服务之间的调用使用一般用feign
4、外部的流量通过服务网关负载均衡
还有淘宝的HSF和亚马逊的Coral Service、华为在电信行业的DSF等等
微服务功能特性
单一职责，这样能聚焦一个指定的业务功能或业务需求。
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，利于敏捷交付
一个服务就是一个独立的实体
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的
微服务允许你利用融合最新技术和不同的言语(要考虑维护和规范)
微服务化的挑战----管理复杂度
康威定律
运维以及监控； 服务升级、版本控制；
超大型分布式系统需要考虑性能问题和更复杂的存储、监控和运维等
个人寄语
技术是为了解决问题而存在的。
架构不是一成不变的，不是说定义了单体架构,SOA架构，就一直是这样；
架构是为了解决问题而慢慢演变的一个过程。其实还有RPC框架；有环境的因素和实际需求共同推动。
架构是一个逐步演变的过程，soa架构也可能发展出注册中心；
就比如esb企业总线和服务网关的概念去趋同的；
比如我2014-2016在项目中的架构使用MQ、可以算是伪分布式架构。
但是从整体上它并不是微服务架构，从架构层面上它不满足当前互联网项目发展的需要；
从个体层面上。esb毕竟不是为服务网关设计出来的，
他有他的历史任务，所以已当前的眼光来看，它是落后的；以当时的眼光来看来看他是一个合适
的解决方案，是满足当时所需的是优秀的
所以重申一下个人观点，技术是为了解决问题而存在的，我们不能说什么技术流行就用什么技术；
我们应该看来这个技术解决了什么问题，然后看看它是否能解决我们的问题；
