构建微服务
微服务向来是我个人更倾向的一种架构风格，它具有更加开放的技术姿态。
通过阅读这本《Building MicroService》，让我对微服务有了更深入的了解，同时也发现了它与DDD、CD是完美契合的。
康威定律
任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大。
组织的架构最终决定系统的架构，如果你存在一个等级森严、层层架构的组织，那么，微服务就不一定适合你的组织。
什么是微服务？
这个世界上既不存在银弹，也不会有免费的午餐。
微服务作为一个新兴的分布式系统架构，它解决了如何实现低耦合、高内聚的问题，同时也带来了很多分布系统特有的复杂性。
微服务是指：一些小而独立的服务联合起来一起工作。
那么，多小算小？
给一个具体的代码行数是不靠谱的，不同的语言实现同样的功能，所需要的行数也是不同。
一般来说，一个team花2周的时间就能实现的功能大小比较合适。
好处
- 技术多样性
- 容灾性
- 伸缩性
- 容易部署
- 与组织结构对应
- 组合性
- 可替换性
挑战
- 切分
- 部署
- 监控
- 安全
- 集成
（使用不同的技术栈来构建微服务）
MicroService vs SOA
微服务是一种特殊的SOA实现方式，就像XP ／ Scrum是敏捷开发的一种实现方式。
进化的架构
构建微服务的过程中，架构师的角色更像是一个城市规划师，而不是一栋建筑的设计师。
架构师需要制定对应的：战略目标、规则、以及实践方式。 有统一标准的监控、接口实现方式和安全措施。
集成
服务集成
理想的集成技术应该是：
- 避免破坏性的改变
- 保持API的技术无限性
- 让消费者简单使用服务
- 隐藏实现细节
共享数据库
共享数据库的方式让数据更容易去共享，但对行为的共享没有任何帮助。
同步 vs 异步
同步没什么好说的。 ：）
异步的交流方式有2种 ：
request/response 或者 event-based
request/response： 一问一答的方式比较传统，也可用于同步的方式。
event-based： 事件驱动,这种方式是基于事物状态的变化，能够高度的解耦。
RPC （Remote Procedure Calls）
RPC的技术能让本地环境方便去调用外部接口，同时也具有较高的性能。
但是它也存在一些特有的问题：
- 技术耦合
- 本地调用不等于远程调用
- 易脆
一些RPC的机制，例如Java RMI，会严重地去依赖某个特定的平台，限制服务器和客户端所使用的技术。
RPC的核心理念是隐藏远程调用的复杂性，但是往往隐藏的过多，本地调用并不等于远程调用。
分布式系统的第一谬误， “网络是稳定的”。
任何RPC机制的最大问题在于，无法分开部署客户端和服务器端。
如果你使用这项技术，未来的更新步骤是锁步的。
REST
REST是基于HTTP本身特性的架构风格，它有三种成熟度模型，详情请查看 Richardson Restful成熟度模型
DRY
DRY原则更多的是：关于避免重复系统的行为和知识，而不是单单代码层面的重复。
实践原则
围绕业务内容建模
多年来的工作经验告诉我们：基于业务边界划分的结构，要远比基于技术内容划分的结构稳定。
《领域驱动设计》里面的限界上下文是一个很棒的出发点， 它提供了一个从业务的角度去划分模块的方式。
拥抱自动化的文化
微服务带来了很多复杂性，克服这些困难的关键是要拥抱自动化开发的文化，如自动化测试，持续交付等等实践。
隐藏实现细节
采取无限技术的方式，例如REST，能够让你更自由地使用不同的技术栈。
尽量隐藏实现的细节，服务的消费者不需要知道服务是用什么语言实现，是用什么样的数据库。
去中心化所有东西
为了让每一个微服务尽可能的独立，去中心化所有的东西能够避免把所有的鸡蛋都放在一起。
独立部署
通过蓝绿或者金丝雀部署方式，可以降低部署的风险。
采用消费者驱动契约的方式能够尽早的发现问题。
隔离失败
理解和计划失败是分布式系统的一部分，通过Bulkheads或者Circuit breakers模式能够有效的控制失败带来的影响。
高度可视化
聚合所有的日志和状态，通过语义监控来观察系统是否正常。 使用correlation IDs可以方便地跟踪系统调用的痕迹。
分布式领域CAP理论
Consistency(一致性), 数据一性
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CA不属于分布式系统，所以只考虑AP和CP。
AP要比CP容易实现，具体用哪一种要看具体业务。
End
这么多年来，我们不断地找到更好的方式去开发系统：
Eric Evans‘s 《领域驱动设计》 帮助我们去了解让代码去呈现真实世界的重要性。
《持续交付》告诉我们如何更加有效率的发布软件到生产环境。
Alistair Cockburn的 六边形架构 告诉我们如何避免把业务逻辑四分五裂的隐藏在各层的架构上。
各种虚拟化平台，如Amazon云、阿里云，允许我们去定制自己所需要的机器。
最近，Netflix公司跟我们分享来一种 高扩展性的架构风格 ，
既微服务架构，这种架构在十年前很难实现，幸运地是，今时不同往日。 ：）