关于Python构建微服务的思考（一）

一：什么是微服务？

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

　　固然啦，关于微服务还有不少种定义，并无一个官方的标准，一般在解释微服务的时候，一般会提起一种面向服务的架构——SOA，其核心的原则就是将应用组织成一独立的功能单元，可远程访问并单独进行操做和更新，简单来讲，就是每一个单元都是一个独立的服务，它能够实现业务的一个方面，并经过接口提供功能，虽然SOA清楚地指出服务应当是独立的进程，可是并未强制使用哪一种协议进行交互，对于部署和配置仍是至关模糊的，SOA服务能够在同一个机器上使用socket经过IPC（进程间通讯）方式进行交互，若要使用内存共享，间接消息队列或远程过程调用（RPC），这是一个很是普遍的定义，只要没用在单个进程中运行全部应用，SOA能够是任何东西。

二：传统的单体架构

　　举例来讲：一个商城，除了要有静态的HTML内容外，还必需要有相关的模块，好比用户模块，订单模块，商品模块，优惠券模块等等，当用户对应用进行操做的时候，会伴随着针对数据库的一些SQL操做，而后再通过渲染返回给HTML的页面，整过过程都至关于在一个应用的总体内进行，较少的对外部服务进行网络请求（好比注册时须要请求第三方短信验证），在经典的LAMP架构中，每一个传入的请求都会在数据库生成关联的SQL查询，而后服务器再使用模板引擎生成相应的HTML进行响应。

这种架构有很明显的优缺点，优势就是：1.咱们能够很容易的开始一个项目；2.简化了数据的设计和组织；3.部署应用也会相对简单

但他也有很明显的缺点：1.咱们若是想增长一些功能的时候，修改代码可能会影响到原来不相关的功能，对某部分代码的错误修改可能致使整个应用的崩溃

　　　　　　　　　　　2.扩展应用的解决方案存在的限制：可部署多个实例，但若期中一个特定的功能占用了全部资源，则会影响整个应用

　　　　　　　　　　　3.随着应用的迭代，代码库的增加，很难保证代码的干净和可控性。

 

 三.微服务架构

以下图所示：

 

如上图所示，这些微服务，诸如电子邮件的外部服务，将提供和单体应用相同的功能集，这个架构中的每一个 组件都使用HTTP协议进行通讯，拖过REST风格的web接口提供服务，每一个微服务都在内部处理本身的数据结构，不须要中心化数据库，使用广泛的数据格式如JSON输入输出数据，任何语言均可生成和使用，最后经过HTTP请求和响应进行传输。整体来讲，微服务是一个轻量级的应用，它能够经过良好的契约提供一组有限的功能，它是具备单一责任的组件，可独立开发和部署。

微服务架构的优势：

1.分离开发团队的注重点，每一个微服务均可由一个团队独立开发，每一次版本迭代只会在服务的内部进行，不会影响其余的应用，低耦合的开发模式，加快项目的进程。

2.若是在现成的微服务应用中进行跨越式的迭代，好比说更换语言和框架，咱们能够把它隔离在一个微服务中，使用独立的数据库，让一小部分用户去试验这个方案，从而不影响整个应用的运行

3.更加灵活的扩展与部署，根据微服务的定义，咱们能够将服务部署在不一样性能的服务器上面，须要消耗CPU的放在性能优良的服务器上面，只消耗内存的（如Redis这种内存数据库）咱们能够部署在CPU稍微较差，而内存较大的服务器上，从而减小了部署的成本

有好确定有坏：

1.微服务若出现不合理的拆分，当你重构一些业务逻辑时，你的代码就会让你搔首踟蹰了，嘻嘻，若是你要实现一些功能，老是要部署两个微服务，或者你改变了一个微服务总会影响另外一个数据模型时，你就该考虑合并两个微服务了

2.在微服务的构建过程当中，使用了不少的网络交互，这也带来了问题，若有因为网络隔离或服务延迟，“商城HTML”没法及时调用相关的服务，这会产生严重的后果

3.假如用户添加的系统中来，进行某些数据操做时，是否是须要同步每个服务，这样作会不会产生冗余呢，保持微服务的隔离的同时又要尽可能避免数据的重复

4.兼容性的问题，可能会出现版本的不一致

5.测试上的问题，众所周知，产品要部署上线时确定要通过相应的测试，可是微服务架构是一个分离的架构，不一样于单体架构，他须要相应的工具才能进行测试，这也是限制微服务开发的一个难题。