近来稍微了解了下微服务的概念，这里记录下自己的理解。主要从以下几个方面
- 单体架构和微服务架构
- 主流框架
- 通信方式
- 设计原则
- 分布式和集群
1. 单体架构和微服务架构
单体架构简单理解为项目的所有源代码都在一处，比较适用于企业内部用，数据量相对较小，基本没有并发。这种情况下，单体架构可以用的很爽，既省事又简单。既然工作的很好，那么为什么现在又会出现微服务架构呢？在我看来主要的原因有两个，一个是数据量大了，一个是并发量高了，这样单体的架构就不以支撑了，为什么这么说呢？因为目前的话，一台tomcat（我是搞Java得）的并发量（同时访问服务器的连接数）最多就几百吧，虽然可以调优，那就最多给你个一两千或者更多，但是想想现在互联网的大量的用户产生的海量的数据，同一时间的请求数有上百万，千万甚至上亿时，单体架构显然不能支撑了，你可能会说，单体可以水平扩展啊，但是想想也没谁这么干吧，首先成本高，并且大量的资源浪费（因为在非常高的并发的地方可能就是系统种某一个模块），还有维护啊，谁脑子进水了谁这么干。其实但凡有海量数据大量用户的系统，那一定是面向普通大众（互联网用户）的系统的，这种系统有大量用户和海量数据，那一定是一个庞然大物了。所以呢，就有了架构升级了，一直演变，到如今微服务架构就很火了。微服务架构说的简单点就是"动刀子",把之前大的系统"拆"出来，我就觉得这个"拆"字，就是微服务的核心（现在心里默默的记住），至于怎么拆，拆了会产生什么难题，怎么解决，我想这便是微服务框架所关心的核心问题了。至于怎么"拆"，这是个高深学问，就像杀猪宰牛，这个我想我们可以向屠夫取经了。可以想到一个场景就是，你去菜场（或者去超市）买猪肉，摊上摆着各种猪肉类别，什么五花肉啊，排骨啊，猪蹄啊，前排肉等，都分的清清楚楚明明白白，是不是？一般不会五花肉夹杂着排骨啊，或者其他的什么鬼的。这想这大概就是"拆"了吧。同样的，各家的系统有各个系统的情况，你家的系统是牛还是猪，你要怎么动刀子，这就是你的高深学问了；还有另外一个场景就是，在超市中的五花肉的包装袋 肯定有多个袋子，用来同时服务更多的消费者。但但但但是，我们的系统可不是拆了就完事了啊，想想看，我们最终的目的还是要将拆分的东西再联系起来，构成一个有机体，对外服务。那么重点来了，我们拆了之后，会产生哪些问题呢，又要怎么解决呢？首先被拆分出来的每个模块都有自己的核心功能，在某个需求中可能同时需要多个模块的数据，那我怎么知道我所需要的在哪个被分割的模块呢？这时我们想到的一个方案就是，每个被拆分的模块你有什么功能，你都集汇总到一个第三方（注册中心）；这样还不够，我只知道你在哪，倒是我不知道我怎么调用，这是就出现的服务调用；有时被拆分的模块应对高并发会水平扩展（集群部署），那么调用时应该调用哪一个（负载均衡）；还有就是如果调用的服务出现了错误或者异常，应该怎么办（容错处理）？这些都是要解决的问题，当然还有其他的一些需要解决的问题
2.主流框架
- dubbo/dubbox
- spring cloud
3.通信方式
- dubbo/dubbox 使用RPC
- spring cloud 使用RESTful
4.设计原则
- 单一职责
- 围绕业务拆分
- 谁创建谁负责
5. 分布式和集群
- 分布式更关注 "拆"
- 集群更关注 "部署"
