为何要微服务化

技术交流群：233513714

 

六大优点

微服务架构相对于传统的SOA，优点也很明显：

一、复杂度可控：在将应用分解的同时，规避了本来复杂度无止境的积累。每个微服务专一于单一功能，并经过定义良好的接口清晰表述服务边界。因为体积小、复杂度低，每一个微服务可由一个小规模开发团队彻底掌控，易于保持高可维护性和开发效率。

二、独立部署：因为微服务具有独立的运行进程，因此每一个微服务也能够独立部署。当某个微服务发生变动时无需编译、部署整个应用。由微服务组成的应用至关于具有一系列可并行的发布流程，使得发布更加高效，同时下降对生产环境所形成的风险，最终缩短应用交付周期。

三、技术选型灵活：微服务架构下，技术选型是去中心化的。每一个团队能够根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。因为每一个微服务相对简单，当须要对技术栈进行升级时所面临的风险较低，甚至彻底重构一个微服务也是可行的。

四、容错：当某一组建发生故障时，在单一进程的传统架构下，故障颇有可能在进程内扩散，造成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其余服务可经过重试、平稳退化等机制实现应用层面的容错。

五、扩展：单块架构应用也能够实现横向扩展，就是将整个应用完整的复制到不一样的节点。当应用的不一样组件在扩展需求上存在差别时，微服务架构便体现出其灵活性，由于每一个服务能够根据实际需求独立进行扩展。

六、功能特定：一个微服务通常完成某个特定的功能，好比消息管理、客户管理等等。每个微服务都有本身的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每个实例多是一个云VM或者是Docker容器。

三大挑战

1.固有的复杂性：微服务架构有不少优势，固然也有其不足。好比微服务应用是分布式系统，由此会带来固有的复杂性。开发者须要在RPC或者消息传递之间选择并完成进程间通信机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。

2.分区的数据库架构：另一个关于微服务的挑战来自于分区的数据库架构。在商业交易系统中同时给多个业务分主体更新消息很广泛。这种交易对于单个应用来讲很容易，由于只有一个数据库。而在微服务架构应用中，须要更新不一样服务所使用的不一样的数据库。使用分布式交易并不必定是好的选择，不只仅是由于CAP理论，还由于今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

3.波及多个服务：最后一个问题在于，微服务架构模式应用的改变将会波及多个服务。好比，假设你在完成一个项目案例，须要修改服务A、B、C，而A依赖B，B依赖C。在单个应用中，你只须要改变相关模块，整合变化，部署就行了。相比之下，微服务架构模式就须要考虑相关改变对不一样服务的影响。好比，你须要更新服务C，而后是B，最后才是A，幸运的是，许多改变通常只影响一个服务，而须要协调多服务的改变不多。

使用微服务构建适合云的新型应用是颇有意义的，由于它让你既利用了横向扩展架构，也利用了纵向扩展架构，还额外获得API的组合，且在整个业务中可重复利用。可能在每一分钟都在交付新服务，这样你就会拥有一个敏捷的且即时响应的应用程序平台，固然这一平台一直在不断改进中，微服务架构也在前进着。

主要周边技术

云VM

DOCKER容器

微服务架构与SOA

微服务与分布式

微服务与数据一致性

微服务与数据库

微服务与PAAS

微服务与自动化部署

微服务与Mesos或者Kubernetes

微服务层面如何提供缓存、权限控制、API统计和监控