微服务概念解析
特点
1 粒度微小
2 责任单一
3 隔离性好
4 管理容易
作用
1 传统软件架构
2 微服务架构
3 单体架构和微服务架构比较
微服务应用场景
1记录型系统System of Record
2交互型系统System of Engagement
3分析型系统System of Insight
微服务架构的缺点
1运维开销及成本增加
2必须有坚实的DevOps开发运维一体化技能
3隐式接口及接口匹配问题
4代码重复
5分布式系统的复杂性
6异步机制
7可测性的挑战
概念
微服务是一种以业务功能为主的服务设计概念，每一个服务都具有自主运行的业务功能，对外开放不受语言限制的 API (最常用的是 HTTP)，应用程序则是由一个或多个微服务组成。微服务的另一个对比是单体式应用程序。 单体式应用表示一个应用程序内包含了所有需要的业务功能，并且使用像主从式架构 (Client/Server) 或是多层次架构 (N-tier) 实作，虽然它也是能以分散式应用程序来实作，但是在单体式应用内，每一个业务功能是不可分割的。若要对单体式应用进行扩展则必须将整个应用程序都放到新的运算资源（如：虚拟机器） 内，但事实上应用程序中最吃资源、需要运算资源的仅有某个业务部分（例如跑分析报表或是数学算法分析），但因为单体式应用无法分割该部分，因此无形中会有大量的资源浪费的现象。
微服务运用了以业务功能的设计概念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能拆分为独立独立部署、独立运行的子系统（能自主执行的个体服务），然后再利用相同的协定将所有应用程序需要的服务都组合起来，形成一个应用程序。若需要针对特定业务功能进行扩充时，只要对该业务功能的服务进行扩展就好，不需要整个应用程序都扩展，同时，由于微服务是以业务功能导向的实作，因此不会受到应用程序的干扰，微服务的管理员可以视运算资源的需要来配置微服务到不同的运算资源内，或是布建新的运算资源并将它配置进去。虽然使用一般的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 会更加地适合发展微服务的运算资源管理技术。总结起来就是：
1. 服务种类根据业务划分
2. 每个服务可独立部署运维且相互隔离
3. 服务之间通过 API 调用服务
4. 服务需保证良好的高可用性
5. 分散式管理以及分散式数据。每个微服务团队有充分自由选择自己团队熟悉的编程语言、数据库和其他中间件等技术栈。
微服务的一些常见误解
关于一些比较概念的澄清：
在同一范畴内比较才有意义：
微服务架构 vs. SOA
两者都是架构风格范畴，但其关注领域与涉及范围不同。SOA更关注企业规模范围，微服务架构则更关注应用规模范围。
微服务组件 vs. 服务组件
两者都是描述业务功能的具体实现，其区别在于粒度不同，此外还有在可管理性、灵活性上的差异。
-------------------------------------------------
概念混淆的不恰当比较
微服务 vs. SOA – 不恰当的比较。
微服务是组件范畴，而SOA是一种架构设计风格。因此应该比较的是微服务架构与SOA。
微服务 vs. API – 不恰当的比较。
API是接口，是业务功能暴露的一种机制。微服务架构是用于实施业务功能的组件架构。因此直接比较它们是没有意义的。
微服务 vs. 服务– 不恰当的比较。
“服务”在不同的场景下有不同的含义，需要进一步澄清其描述的语境，是指服务实施、服务暴露、服务定义还是其他？
微服务亦是如此，需要有特定语境才可判断比较是否有意义。
特点
搭建一个微服务架构需要具备四大特性
1 粒度微小
微服务的粒度是根据业务功能来划分的，对于某些复杂的业务来说，可能粒度较大，
对于相对简单的业务而言，可能粒度较小。
总之，微服务的粒度可大可小，但往往我们更希望它尽可能的小，
但又不希望微服务之间有任何的依赖，因此粒度的划分是非常考验架构师水平的事情。
2 责任单一
我们需要确保每个微服务只做一件事情，也就是我们经常提到的“单一职责原则”，
该原则对微服务的划分提供了指导方针。
3 隔离性好
每个微服务相互隔离，且互不影响。
也就是说，每个服务运行在自己的进程中。众所周知，进程之间是隔离的，是安全的，而进程内部或线程之间资源共享的。
换句话说，一个微服务出了问题，不会影响到其它微服务受到任何影响。
4 管理容易
随着业务功能不断增多，微服务的数量也会逐渐增加，我们需要对微服务提供自动化部署与监控预警的能力，才能更加高效地管理微服务。
微服务架构的特点非常明显，可能还有很多，但同时微服务架构也给我们带来了许多挑战。
作用
在之前传统的软件开发架构中尤其是单体应用中，我们会发现随着系统的业务需求越来越大，系统越来越臃肿，不仅难以管理和维护，也不利于横向扩展，这就会限制软件的开发以及公司的发展。
1 传统软件架构
扩展后
只需将这个应用程序复制一份，一模一样的程序，将其部署到另一台 Web Server 上，下方还是连接到同样的 Database，只是在这些 Web Server 的上方架设一台 Load Balancer（负载均衡器，简称 LB）。请求会首先发送到 LB 上，通过 LB 上的路由算法（例如轮询或哈希），将请求转发到后面具体的 Web Server 上，这类请求转发技术被称为Reverse Proxy （反向代理）。由于进入 LB 的请求（流量）被均衡到下方各台 Web Server 中了，流量得到了分摊，负载得到了均衡，因此该技术也称为 LoadBalance（负载均衡）。如果流量加大，理论上可以无限水平扩展，只要 LB 扛得住巨大的流量。
通过以上技术方案，将负载进行了均衡，一定程度上缓解了流量对 Web Server的压力，但此时却造成了大量的系统资源浪费，比如对系统资源暂用率不高的 ModuleA 与 Module B 也进行了水平扩展，其实我们只想对 Module C 进行水平扩展而已。
2 微服务架构
在设计阶段，架构师将产品功能拆分为若干微服务，为每个微服务设计 API 接口（例如REST API），需要给出 API 文档，包括 API 的名称、版本、请求参数、响应结果、错误代码等信息。在开发阶段，开发工程师去实现 API 接口，也包括完成 API 的单元测试工作，在此期间，前端工程师会并行开发 Web UI 部分，可根据 API 文档造出一些假数据（我们称为“mock 数据”），这样一来，前端工程师就不必等待后端 API 全部开发完毕，才能开始自己的工作了。在测试阶段，前后端工程师分别将自己的代码部署到测试环境上，测试工程师将针对测试用例进行手工或自动化测试，随后产品经理将从产品功能上进行验收。在部署阶段，运维工程师将代码部署到预发环境，测试工程师再次进行一些冒烟测试，当不再发现任何问题时，经技术经理确认，运维工程师将代码部署到生产环境，这一系列的部署过程都需要做到自动化，才能提高工作效率。在以上交付流程中，开发、测试、部署这三个阶段可能都会涉及到对代码行为的控制，我们还需要制定相关开发模式，以确保多人能够良好地协作。在以上交付流程中，开发、测试、部署这三个阶段可能都会涉及到对代码行为的控制，此外还需要制定相关开发模式，以确保多人能够良好地协作。
通过比较我们会发现微服务比我们传统的软件架构更加灵活和容易扩展，当然也会有一些挑战，比如对服务的划分，管理以及运维要求都是比较高的
3 单体架构和微服务架构比较
单体架构 微服务架构
整体部署 分布式部署
紧耦合 松耦合
基于整体系统扩展 基于独立服务按需扩展
集中式管理 分布式管理
应用无依赖管理 微服务中服务之间有较强依赖
局部修改整体部署 局部修改局部部署
故障全局性 故障隔离非全部
代码会臃肿、难维护 代码易于理解，容易维护
开发效率低 开发效率高
资源利用率低 资源利用率高
部署简单 部署复杂
微服务应用场景
1、记录型系统(System of Record)
将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
2、交互型系统(System of Engagement)
也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。
3、分析型系统(System of Insight)
则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。
微服务架构的缺点
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
1、运维开销及成本增加：
整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
2、必须有坚实的DevOps开发运维一体化技能：
开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
3、隐式接口及接口匹配问题：
把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
4、代码重复：
某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
5、分布式系统的复杂性：
作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
6、异步机制：
微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
7、可测性的挑战：
在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意
大家可以点击加入群：【Java高级架构进阶群】 里面有Java高级大牛直播讲解知识点 走的就是高端路线，（如果你想跳槽换工作 但是技术又不够 或者工作上遇到了瓶颈 ，我这里有一个JAVA的免费直播课程 ，讲的是高端的知识点基础不好的误入哟，只要你有1-5年的开发经验可以加群找我要课堂链接 注意：是免费的 没有开发经验误入哦）
点击链接加入群聊【Java高级架构进阶群】：群地址
写在最后：欢迎留言讨论，加关注，持续更新！！！