微服务
为什么要提出微服务？
原本的单体架构应用是将一整个应用放在webapp下，
- 将整个应用打成war包，对于开发语言上是由限制的，整个应用只能使用java系列的语言，而微服务技术栈不受限，不同的服务可以使用不同的技术栈
- 修改某一个小模块就需要部署整个应用，尤其是特别大的项目，部署一次很麻烦且费时，而微服务架构中每个服务都是一个独立的业务单元，服务与服务之间是独立的
什么是微服务？
马丁提出微服务架构的概念时列出来了一些对于微服务的描述，
微服务是一种架构模式
- 将单一应用分成一组小服务，根据业务模块划分服务
- 每个服务可独立部署且相互隔离
- 通过轻量级API调用(如HTTP调用)
- 服务需保证良好的高可用性
既然要拆分，那么到底如何拆分服务呢，首先要遵守两个基本前提
- 业务独立性 保证每个微服务是具有业务独立性的单元
- 团队自主性 每个团队成员不超过十个人
微服务的优点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 复杂的系统可以使用不同的语言进行开发，语言无关、平台无关，可以选择更适合的语言、工具或者平台来开发服务本身
- 可以按需伸缩
微服务的缺点
- 微服务会导致服务增多，且技术复杂
- 对于运维要求相对提高
- 查找问题变得更加复杂
- 存在分布式的各种问题，如数据一致性问题
- 多个应用存在依赖性，接口调整成本高，修改一个微服务的API可能所有涉及到的微服务都要修改
- 重复代码，很多服务可能会使用相同的功能，可能需要各个服务都要开发这一功能
对于微服务之间的进程间调用，能访问一次就不要访问多次，尽量的粗粒度的返回更多的东西；而对于进程间的调用，是细粒度的
与SOA的区别
- SOA是企业级的，自顶向下开展实施；微服务时团队级的，自底向上开展实施
- SOA服务是由多个子系统组成，粒度大；微服务一个系统拆分为多个服务，粒度小
- SOA服务之间使用企业服务总线来进行交互的集中式的服务架构；微服务是无集中式总线，松散的服务架构
- SOA是单体架构系统，相互依赖，部署复杂；微服务可以独立部署
是否使用微服务
- 看业务规模，单体应用太大不好维护时