Spring Cloud和微服务入门1：微服务简介；_使用各自相对独立的1套技术栈-优快云博客

1.原先单体应用的痛点；

（1）项目庞大，不仅仅体现在代码中，也会体现在表中；

● 其实，如果我们的项目很庞大，有很多表；；；；；但是，只要我们的技术文档完整、注释明了、表的描述清晰、表的字段名命名规范，一个新人过来的时候，想要理解这些表也不是很难；；；；；但是，在实际中，我们多多少少不会完全按照规范来，有的时候图省事会偷懒，那么一个新人过来的时候，想要理解这些表（表之间的关联关系，表的含义，表数据量等）就会比较困难；

● 即，单体应用中，所有的表都放在了一起，项目越来越大，表也会越来越多；；；；；而且，到后来，也有可能有些表已经废弃了，但却没有人去删除；

（2）容易出现尾大不掉的情景；

● 单体应用，当项目很大时，会很难调整、很难重构、架构难优化，而且也没有人敢承担其中的风险；

（3）代码风格、组件，不统一；

● 一个团队中，会对代码风格作一定规范的，但是规定往往也不会过于死板，也是允许团队成员在风格上有些微差异的；；；；；但是，当所有人都维护一个项目时，就会出现不同的代码风格；；；；；这就会出现，不同开发者之间不熟悉甚至看不懂对方写的代码，代码可读性就会很差；

● 比如A喜欢使用这个日志组件，而B喜欢另一个日志组件；即，在同一项目中，我们使用了多个【实现同样功能的组件】，这就不咋好了；

（4）技术难以升级；

● 技术往往是需要升级的，项目在技术上升级迭代，也是很正常的；

● 如果项目过于庞大，我们在升级某个组件的时候，就可能会出现很多冲突和不兼容的地方；（出现冲突后，代码报红还好；；；就怕那种，代码不报红，但项目上线后出错的情况）

（5）正是因为单体应用的这些痛点，所以出现了服务化；

2.什么是服务化；

（1）拆分：把一个大项目拆成多个小项目，把原先聚集在一起的功能拆分成多个不同的功能；（一般我们会从业务功能角度，去拆分）

（2）独立：虽然每个模块不足以支撑所有的功能（比如单靠【商品模块】是无法支撑完整的电商功能的），但是对于每个模块，我们至少可以做到独立开发、独立部署、分工和责任明确；

（3）通信：通信一定不能是全耦合的，必须要通过调用（RPC调用或者Http调用）来实现通信；即，A模块想要和B模块通信，A模块不能把B模块具体的代码实现给引过来，即B模块的代码不能是在A模块这儿跑的；；；；；也就是说，A模块要想和B模块通信，A模块是不应该、不需要关心B模块具体怎么实现的；

3.什么是微服务；

维基百科的解释：

（1）微服务以【专注于，单一职责与功能的小型功能区块】为基础；每一个微服务，其自身都是独立的；其职责也比较单一，功能比较小型；；；；；然后，利用模块化的方式，把多个微服务进行组合，从而组合出一个大型的的复杂的应用程序；

（2）不同的微服务区块，使用与语言无关（Language-Independent/Language agnostic）的API（API集）进行相互通信；