微服务简单说

1 微服务架构定义

微服务一词源自 马丁·福勒（Martin Fowler) 在2014 年的一篇博客：Microservices 该文章中对微服务定义以下：

the microservice architectural style [1] is an approach to developing
a single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often an
HTTP resource API. These services are built around business
capabilities and independently deployable by fully automated
deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage technologies.

微服务架构风格是将单体应用程序 拆分为多个小型的服务 而且每一个服务在独立的进程中。服务间的通讯采用轻量级通讯的机制 一般是HTTP方式提供API 来实现。这些服务经过自动化部署的方式进行独立部署。每一个服务能够根据自身的特色采用不一样的语言开发同时也可使用不一样的数据存储技术。

服务的拆分是基于业务和公司的组织架构进行拆分，也称之为康威定律。

另外 Adrian Cockcroft 更是将微服务比喻成 细粒度的 SOA（面向服务的架构）

2 单体架构定义

虽然我对微服务的定义进行解释，可是若是想更深层次的了解微服务 咱们不得不先从单体架构提及。

单体架构就是 将 web项目应用实例 的全部功能模块打包到一块儿并放在一个web容器中运行的系统。 例如 咱们的一个电商网站 其中包含 商品模块 订单模块 等咱们能够经过maven多模块 或者 放入到不一样的包中来区分。 可是最终仍是将其打包成一个war 部署在咱们的tomcate中。

单体架构好处

1. IDE友好支持：
   NetBeans、Eclipse、IntelliJ 这样工具专门为单体应用设计。 你只须要使用其中一种 就能够在你本地机器上进行 开发 调试 部署。
2. 方便测试：
   测试人员只须要测试单个应用便可。新开发的功能部署完成就能够测试全部的功能。
3. 容易部署：
   打包成war包放入咱们的服务器 或者打包成一个课执行的jar 执行jar包便可。

单体架构缺点

随着业务规模的发展咱们的单体架构会出现以下问题

1. 项目愈来愈复杂（随着业务发展模块会愈来愈多）
2. 项目总体编译耗时长
   咱们开发人员在进行开发和调试过程当中须要化大量的时间在无用的从新编译上。
3. 合并代码容易产生冲突
   在进行多个需求并行开发时每一个分支会涉及到不少相同的代码以致于极易产生冲突。
4. 新功能上线周期长
   每次进行新功能的开发和bug修改很难预估对项目总体的影响，那就须要进行所有功能的测试。然而这个测试是比较耗时的 致使咱们上线时间的延长。
5. 项目稳定性差
   项目中不重要的功能模块出现bug会致使整个服务瘫痪。
6. 只能作横向扩展
   因为整个功能模块都在一个实例中，咱们对整个服务实例进行扩展，没法针对具体的功能进行垂直的拆分。也没法对某个功能进行单独的硬件升级。

7. 不敢作新的技术的尝试
   因为咱们的项目是单体的架构，项目成员必须使用同一种技术栈进行项目的开发。切换新的技术和语言要对整个项目进行重头开发。这使得尝试新的语言变得比较困难。

   微服务架构好处

   简单点说微服务的好处正式用来弥补单体架构的不足的。具体的好处以下：

8. 因为拆分为多个小服务每一个服务比较容易理解
9. 每一个微服务有启动调试速度快，无需过多的等待编译时间
10. 咱们能够针对每一个服务方便进行横向和纵向的扩张
11. 根据服务特色 针对性的进行服务器硬件升级
12. 单个服务的升级不要其余服务的协调
13. 服务拆分和团队组织更匹配

14. 尝试新的技术变得更容易

4 微服务架构与SOA的区别

1. SOA是面向服务架构。而微服务也是面向服务架构。
2. 微服务架构能够理解成更细力度的 SOA。
3. 微服务架构强调要采用轻量级的通讯。
4. 微服务架构强调的是基于业务作细粒度的拆分和部署。
5. 微服务构架强调每一个服务有独立的数据库。

个人我的理解就是微服务是在SOA 上进一步的延伸而产生的新名词。

5 微服务面临的困难

微服务不是银弹，使用微服务业务也有困难须要解决。当咱们将服务拆分多个服务 多是几十个服务 也有多是上百甚至上千个服务。这个多服务如何区治理就是咱们要面临的困难，具体细分的话包含以下内容：

1. 单体系统架构如何拆分
2. 多个服务之间的通讯
3. 服务API文档
4. 服务注册发现
5. 服务负载均衡
6. 服务网关
7. 分布式追踪
8. 日志聚合
9. 集中配置
10. 容错限流
11. 服务自动化部署
12. 监控告警

若是你的项目代码模块 代码逻辑 比较混乱是不可以经过微服务来解决的。引入微服务须要对整个项目的功能进行梳理划分后才能在考虑切换为微服务。

参考文献

和坚 简书博主当咱们在说微服务治理的时候究竟在说什么：
Rick Osowski：微服务介绍
承诺一时的华丽 简书博主：Go - Micro微服务框架实践 - 相关概念（六）
每日一拾 简书博主：架构设计漫步：从单体架构、SOA到微服务