标签：服务 部署 数据库 可用性 API 应用 一致性 设计

走向单体地狱：

有一个成功的关键业务应用，它已经发展成为一个只有少数开发人员能够理解的巨大单体。它使用了过时、非生产性技术编写，使得招聘优秀开发人员变得非常困难。应用变得难以扩展，不可靠。因此敏捷开发和应用交付是不可能的

微服务-解决复杂问题：

1、服务也可以使用异步、基于消息的通信；

2、通信是由一个称为 API 网关（API Gateway）的中介负责。API 网关负责负载均衡、缓存、访问控制、API 度量和监控（Nginx…）;

3、每个服务都拥有各自的数据库

优缺点：

优点：

a. 把可能会变得庞大的单体应用分解成一套服务，如远程过程调用（RPC）驱动或消息驱动 API

b. 使得每个服务都可以由一个团队独立专注开发，由于服务较小，使用当前技术重写旧服务将变得更加可行

c. 微服务架构模式可以实现每个微服务独立部署，微服务架构模式使得持续部署成为可能。

缺点：

a. 一个缺点就是名称本身。微服务这个术语的重点过多偏向于服务的规模，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用以方便应用敏捷开发和部署。

b. 开发者需要选择和实现基于消息或者 RPC 的进程间通信机制，由于目标请求可能很慢或者不可用，他们必须要编写代码来处理局部故障，模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多

c. 分区数据库架构，在基于微服务的应用中，你需要更新不同服务所用的数据库。通常不会选择分布式事务，不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理。你最后不得不使用基于最终一致性的方法，这对于开发人员来说更具挑战性

CAP: Consistency(一致性)：所有的节点得到的数据应该是一样 Availability(可用性):所有节点保持高可用性 Partition to lernece(分区容忍性):指的是网络意义上的分区，节点之间不能通信的时候，系统可以正常提供服务、 在保证CP的情况下，虽然没办法保证高可用性，但这不意味着可用性为0，我们可以通过合理的设计尽量的提高可用性，让可用性尽可能的接近100%。同理，在AP的情况下，也可以尽量的保证数据的一致性，或者实现弱一致性，即最终一致性。

d. 测试微服务应用也很复杂

e. ……

微服务实战：

10000 个网站中有超过 50% 使用 NGINX，这主要是因为它有作为反向代理服务器的能力。你可以把 NGINX 放在当前应用甚至是数据库服务器之前以获取各种功能 —— 更高的性能、更高的安全性、可扩展性、灵活性等。

参考：DocsHome/microservices: Microservices from Design to Deployment 中文版 《微服务：从设计到部署》 (github.com)

标签：服务,部署,数据库,可用性,API,应用,一致性,设计
来源： https://www.cnblogs.com/l-926/p/16589531.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。