building_microservices
微服务
微服务：一些协同工作的小而自治的服务。
- 很小：服务专注某个边界内的业务。越小，独立性的好处就越大，同时管理大量服务也会越复杂。
- 自治性：
- 一个微服务就是一个独立的实体，可以独立地部署在PAAS上，也可作为一个操作系统进程存在。
- 服务之间均通过网络调用进行通信，解耦。
微服务的好处
- 技术异构性：因为每个服务都通过网络通信，良好的API设计就可以满足业务需求，每个服务内部具体实现可以迥然不同；
- 弹性：单服务的系统可以通过在不同机器上部署多个实例来减少功能的完全不用概率，而微服务系统本身就能处理好服务不可用和功能降级问题。
- 扩展：单服务只能作为整体进行扩展，多个微服务则只需要对需要扩展的服务进行扩展。
- 简化部署：整体部署，局部部署。
- 与组织结构想匹配
- 可组合性
- 可替代性的优化
面向服务的架构
SOA（Service-Oriented Architecture）：
- 包含多个服务
- 服务组合最终提供一系列功能
- 一个服务一独立的形式存在于操作系统进程中
- 服务之间通过网络调用
它在实施中遇到的问题：
- 通信协议的选择
- 第三方中间件的选择
- 服务的粒度的确定
其实可以认为微服务是SOA的一种特定方法。
其他分解技术
- 共享库：所有的语言都支持共享库，这个是代码层面上的复用。但是无法选择异构技术，非动态链接库部署也不方便；
- 模块：有的语言提供了模块分解技术，运行模块在不停止整个进程的情况下进行局部替换。但是强调模块生命周期，非常复杂；
没有银弹
微服务不是免费的午餐，更不是银弹。如果想得到一条通用准则，微服务是错误的选择。一个最大的挑战是需要面对所有分布式系统的复杂性。
演化式架构师
与建造建筑物相比，在软件中我们会面临大量的需求变更，使用的工具和技术也具有多样性。绝大多数情况下软件交付后还需要响应用户的变更需求。
架构师必须改变从一开始就要设计出完美产品的想法，相反，我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统。
作为一个架构师，不应该过多的观众区域内发生的事情，而应该多关注区域总监的事情，或者时保证我们能对整个系统的健康状态进行监控。
如何搭建服务
什么服务是好的服务：
- 松耦合：服务之间松耦合，修改一个服务不需要修改另一个服务；
- 搞内聚：将相关的细纹聚集在一起，当需要修改某个行为，只需要修改一个地方；
限界上下文：一个由显式边界限定的特定职责。
限界上下文有明确的对外接口，也有明确的对外接口。 思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够听过的功能来考虑。
集成
集成是微服务相关技术中最重要的一个。
理想的集成技术应该：
- 避免破坏性修改： 消费方不随着生产方的修改而修改；
- 保证API的技术无关性：微服务之间的通信方式的技术无关性很重要；
- 服务易于消费方使用；
- 隐藏内部实现细节；