微服务架构入门

微服务架构入门

1. 微服务简介

微服务是一种架构风格，一个大型的复杂软件由一个或多个微服务组成。系统中每一个微服务均可以被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成任务。在全部状况下，每一个任务表明这一个小的业务能力。

微服务的核心思想是：一个完整的应用由多个小的、相互独立的微服务组成，这些微服务运行在本身的进程中，开发和发布都没有依赖。不一样微服务经过一些轻量级交互机制来通讯，例如RPC、HTTP等，服务可独立拓展伸缩，每一个服务定义了明确的边界，不一样的服务甚至能够采用不一样的编程语言来实现，由独立团队维护。简单的来讲，一个系统的不一样模块转变成不一样的服务！并且服务可使用不一样的技术加以实现！

微服务的目的是为了根据业务有效拆分应用，实现敏捷开发和部署。

2. 微服务应用与总体式应用以及SOA的区别

2.1 与总体式（单体）应用的区别

微服务与总体式应用的主要差别在于组装应用组件，微服务架构将相关联的业务逻辑及数据放在一块儿造成独立的边界，其目的是在不影响其余应用组件（微服务）的状况下更快地交付并推出市场。

	总体式应用	微服务应用
进程数	将全部功能放到同一个进程中	将功能的每一个元素放置到分离的多个服务进程中
拓展方式	经过复制整个应用到多台服务器实现拓展	经过将不一样的服务分布于不一样的服务器，并按需复制服务的方式实现拓展
快速响应变动	随着云化以及应用功能变得愈来愈频繁，总体式应用在快速响应市场上显得愈来愈力不从心。部分更新，都须要从新部署整个应用	部署和升级都是独立的，有助于大大提升系统变动的敏捷性。
团队结构	团队结构呈现垂直化，每一个团队专门负责专门的一块，好比分为：UI设计团队、中间件团队、业务开发团队、数据库管理团队等。	团队结构呈现扁平化，每一个团队服务一整个业务能力，团队中包含UI人员、中间件人员、业务开发人员和数据库管理人员，或者是全栈人员。
可用性	一个服务的不稳定可能致使整个应用出现问题	一个服务不稳定，影响范围比较小
创新性	很难引入新的技术和框架，全部功能都使用的同一种框架	每一个微服务可使用不一样的语言和框架，引入新技术方便

2.2 与SOA的区别

看了不少网上对微服务和SOA区别的见解，分为两种，一种是对区别侃侃而谈，列举了不少，另外一种认为微服务实际上是SOA的一种架构实现。从中能够看出微服务和SOA仍是有不少类似之处的，只是针对业务需求进行区别设计。

若是非要说区别的话，微服务架构与SOA最主要的区别在于：微服务再也不强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

3. 微服务架构的一些特性

1. 经过服务实现应用的组件化

微服务架构中将组件定义为可被独立代替和升级的软件单元，在应用架构设计中经过正总体应用切分红可独立部署升级的微服务方式进行组件化设计。

2.围绕业务能力组织服务

以业务能力为出发点组织服务，微服务团队的组织结构必须是跨功能的（好比：即管应用也管数据库），一般团队功能不会太大。

3. 产品而非项目模式

传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护，微服务架构则倡导一个团队应该负责一个“微服务”完整的生命周期，“谁开发，谁负责”。

4. 智能端点和管道扁平化

微服务架构主张将组件通信的相关业务逻辑/智能放在组件端点侧而非放在通信组件中，通信机制或组件应该尽可能简单及松耦合。

5. “去中心化”治理

总体式应用每每倾向于采起单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每一个微服务能够考虑选用最佳工具完成，如不一样的编程语言。

6. “去中心化”数据管理

微服务架构倡导采用多样性持久化的方法，让每一个微服务管理其自由数据库，并容许不一样微服务采用不一样的数据持久化技术。

7. 基础设施自动化

云化及自动化部署等技术极大地下降了微服务构建、部署和运维的难度，经过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。

8. 故障处理设计

微服务架构所带来的一个后果就是必须考虑每一个服务的失败容错机制。所以，微服务很是重视创建架构及相关业务指标的实时监控和日志机制。

9. 演进式的设计

微服务应用更注重快速更新，所以系统会随时间不断演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是总体式应用，但逐渐朝微服务应用架构演进，总体式应用还是核心，但新功能将使用所提供的API构建。再如在某微服务应用中，可代替模块设计的基本原则，在实施后发现某两个微服务常常必须同时更新，则这可能意味着应将其合并为一个服务。

4. 微服务的优缺点

优势：

• 每一个服务都比较简单，能够提供更高的灵活性；
• 微服务架构的方式是松耦合的，能够提供更高的灵活性；
• 微服务可经过最佳及合适的不一样开发语言与工具（好比不一样的数据库）进行开发，可以作到有的放矢地解决针对性问题；
• 每一个微服务可由不一样团队独立开发，互不影响，加快推出市场的速度；
• 微服务架构是持续交付的巨大动力，容许在频繁发布不一样服务的同时保持系统其它部分的可用性和稳定性。

缺点：

微服务的想法在实践上是好的，单当总体实现时也会呈现出复杂性。

• 运维开销及成本增长：总体应用可能只须要部署至一小片应用服务区集群，而微服务可能变成须要构建/测试/部署/运行数十个独立的服务，并可能须要支持多种语言和环境。这致使一个总体式系统若是由20个微服务组成，可能须要40-60个进程。
• 必须具备DevOps开发运维一体化技能：开发人员须要熟知运维与投产环境，开发人员也须要掌握必要的数据存储技术如NoSQL，具备较强DevOps技能的人员比较稀缺。
• 隐式接口与接口匹配问题：把系统分为多个协做组件后会产生新的接口，这意味着简单的交叉变化可能须要改变许多组件，并须要协调一块儿发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，因为集成点的大量增长，微服务架构会有更高的发布风险。
• 代码重复：某些底层功能须要被多个服务所用，为了不将”同步耦合引入到系统中“，有时候须要向不一样服务添加一样的代码，这就会致使代码重复。
• 分布式系统的复杂性：做为一种分布式系统，微服务引入了复杂性和其余若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差别化的工做负载等，开发人员须要考虑以上的分布式系统问题。
• 异步机制：微服务每每使用异步编程、消息并行机制，若是应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
• 可测性的挑战：在动态环境下服务间的交互会产生很是微妙的行为，难以可视化及全面测试。经典微服务每每不过重视测试，更多的是经过监控发现生产环境的异常，进而快速回滚或采起必要的其余行动，但对于特别在乎风险规避监管或投产环境错误会产生显著影响的场景下须要特别注意。
• 部署复杂：一个单体应用只须要在复杂均衡器后面部署各自的服务器就行了。每一个应用实例是须要配置诸如数据库和消息中间件等基础服务。相比之下，一个微服务应用通常由大批服务构成，这就造成大量须要配置、部署、扩展和监控的部分。除此以外，你还须要完成一个服务发现机制，以用来发现与它通信服务的地址（包括服务器地址和端口）。

5. 微服务的取舍

1. 在合适的项目，合适的团队，采用微服务架构收益会大于成本。
2. 微服务架构有不少吸引人的地方，但在拥抱微服务以前，也须要认清它所带来的挑战。
3. 须要避免为了“微服务”而“微服务”。
4. 微服务架构引入策略 – 对传统企业而言，开始时能够考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

6. 名词解释

6.1 服务化架构

服务化是一种架构风格，以服务、数据为中心，构建服务化架构，具有灵活、按需组合的能力。

6.2 服务化特征

• 单一职责：专一一件事，高内聚、低耦合；
• 远程隔离：服务必须支持进行隔离；
• 独立性：服务可独立开发，测试，构建和部署；
• 轻量级：小且灵活；

6.3 服务接口隔离

接口是服务与外界通信的惟一方式，接口契约化，标准化，跨版本兼容。

6.4 服务自治

服务可独立发展，独立发布，独立升级，服务在开发和运行态可视、可管、可测、可维、故障自愈。

6.5 服务降级

指经过必定的策略，以自动或人工管理的方式对系统中非重要服务进行下线或控制服务提供量的一种服务治理手段，以确保系统在高峰期提供更多的资源给重要服务。

6.6 服务熔断

服务熔断也称服务隔离，不少地方也成为过载保护，在系统中，因为某些缘由使得服务出现了过载现象，为了防止形成整个系统故障，从而采起的一种保护措施。

服务熔断和服务下降的异同

相同点：

1. 目的很一致：都是从可用性可靠性着想，为防止系统的总体缓慢甚至崩溃，采起的技术手段；
2. 最终表现相似：对于二者来讲，最终让用户体验到的是某些功能暂时不可达或不可用；
3. 粒度通常都是服务级别：业界也有很多更细粒度的作法，好比作到数据持久层（容许查询，不容许增删改）；
4. 自治性要求很高：熔断模式通常都是服务基于策略的自动触发，降级虽然说可人工干预，但在微服务架构下，彻底靠人显然不可能，开关预置，配置中心都是必要手段；

不一样点：

1. 触发的缘由不太同样：服务熔断通常是某个服务（下游服务）故障引发，而服务降级通常是从总体负荷考虑；
2. 管理目标的层次不太同样：熔断实际上是一个框架级的处理，每一个微服务都须要（无层级之分0），而降级通常须要对业务有层次之分（好比降级通常是从外围服务开始）；
3. 实现方式不太同样。

参考：

什么是微服务：https://blog.csdn.net/fly_zhy...

什么是微服务架构：https://www.roncoo.com/articl...

你不肯意作微服务架构的十个理由：https://blog.csdn.net/gsying1...

SOA和微服务架构的区别：https://www.zhihu.com/questio...

微服务和SOA的区别：https://www.zhihu.com/questio...