基于服务架构的世界
微服务与SOA的共同特征
- 基于服务的架构的一个共性是他们一般都是分布式架构，也就是服务组件都是通过远程访问协议来实现的，例如 REST、SOAP、AMQP、JMS、MSMQ、RMI或者.Net Remoting.
不幸的是，凡事都有代价，享受分布式系统的优点也一样。与优点相伴的缺点则是复杂性的增加和投入的增长。维护服务合约、选择正确的远程访问协议、处理不响应的或不可用的服务、加密远程服务和管理分布式事务，这些还只是构造基于服务的架构时许多复杂问题中的一部分。本章中，我会描述这些与基于服务的架构有关的复杂问题。
服务合约
服务合约是服务提供者（通常是远程的）和使用者（客户）之间使用合约语言（XML、JSON、Java Object等）约定数据输入和数据输出的一份协议。
安全性
对微服务而言，安全问题成为挑战主要是因为没有一个专门处理安全问题的中间件组件。相反地，每个服务必须各自处理安全性问题，或者在某些情况下需要增强API层以使之更加智能地处理应用的安全性问题。
服务可用性
服务可用性是指远程服务及时地接受请求的能力，服务可用性跟服务的可连接性有关，因此客户能够做的并不多，只能要么多试几次，要么在可能的情况下把请求放入队列，以后再处理。
微服务架构的好处
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。
- 第二，这种架构使得每个服务都可以有专门开发团队来开发。
- 第三，微服务架构模式是每个微服务独立的部署。
- 最后，微服务架构模式使得每个服务独立扩展。
微服务架构的不足
- 『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。
- 另外一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。
- 另外一个关于微服务的挑战来自于分区的数据库架构。
- 测试一个基于微服务架构的应用也是很复杂的任务。
- 另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。
下一代微服务：Service Mesh
微服务带来的复杂度让企业头疼，尤其是服务间通信，如何保证服务间通信的端到端性能和可靠性，催生了下一代微服务 Service Mesh。
Service Mesh 是服务间通信层，可以提供 安全、快速、可靠的服务间通讯。
技术的先进性是为了保障业务需求的快速变化和发展，而不是一味追求新兴。一方面会关注新技术的最新动向，另一方面在考虑落地时，也要关注新技术的可靠性和有理可循，有无业界最佳实践背书。
- 微服务和容器共生：容器和微服务相辅相成，天生一对。Docker的成熟，让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟，微服务架构将逐步落地传统企业。
链接