微服务架构浅谈(一)

一、单体式应用和微服务架构的优劣
1、单体式应用
应用核心是业务逻辑，有定义服务、域对象和时间的模块完成。围绕着核心的是与外界打交道的适配器，适配器包括数据库访问组件、声寒和处理消息的消息组件，以及提供API或者UI访问支持的web模块等，虽然是模块化的逻辑，但是最终还是会打包并部署为一个单体式的应用。这种开发风格是最常见的，因为IDE和其他工具都擅长开发一个简单应用，这类应用易于调试，只需要简单运行此应用，就可以完成端到端的测试，单体式应用也已于部署，只需要把打包应用放到服务器端，通过负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早起这类应用运行时没有问题的。
劣势：这种方法有很大的局限性，一个简单的应用会随着时间推移而逐渐变大，一旦医用变成一个又打又复杂的怪物，那开发团队是很痛苦的，敏捷开发和部署举步维艰，其中最主要的问题就是这个引用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变得非常困难，并且非常耗时。如果代码难于理解就不可能被正确的修改。
单体式应用也会降低开发速度，应用大、启动时间会更长，生产效率会受到极大的影响。不利于持续性开发，部署也会很艰难，在单体式应用中如果不同模块发生资源冲突时，扩展就非常困哪，
单体式应用的可靠性也是面临的一个问题，因为所有模块都是运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用工事例都是唯一的，这个bug将会影响到整个应用的可靠性。并且采用新架构和语言非常困难。
总结：一开始有一个很成功关键的应用，后来变成一个巨大无法理解的怪物，因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难，应用无法扩展，可靠性很低，最终敏捷性开发和部署变得无法完成。
2、微处理架构–处理复杂事务
许多公司，比如Amazon、eBay和NetFlix，通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。每个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。运行时，行程管理服务由多个服务实例构成。每一个服务实例都是一个Docker容器。为了保证高可用，这些容器一般都运行在多个云VM上。服务实例前是一层诸如NGINX的负载均衡器，他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求，例如缓存、权限控制、API统计和监控。
这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。每种服务都有自己的数据库，另外，每种服务可以用更适合自己的数据库类型，也被称作多语言一致性架构。
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
优势：
a、通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
b、这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。
c、微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
d、微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。
劣势：
a、微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
b、在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
c、微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。
d、部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成。例如，根据Adrian Cockcroft，Hailo有160个不同服务构成，NetFlix有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制（后续文章中发表），以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。

总结：构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。