|
|
大概在五月份的时候，刚刚上了他们的java进阶，所以可以分享一些内部资料，跟我个人的学习心得，
提取码：5678
心得如下， 其实，传统的开发模式，我们一般称为项目心态，就是以乙方心态给甲方做项目。
一旦项目开发完成，软件将移交给维护/实施部门，或者是乙方交给甲方，然后开发团队就可以解散掉了。而微服务要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，这也就是我们说的产品心态。产品心态下的软件质量要明显好于项目心态。Amazon 的理念就是“You build, you run it”，这也正是 DevOps 的文化理念。
微服务的应用致力松耦合和高内聚，所以更倾向于 REST，而不是复杂的协议（如 WS 或者 BPEL 或者集中式框架），或者采用轻量级消息总线（如 RabbitMQ 或 ZeroMQ 等）来发布消息。 这是跟传统的集中式管理很大区别的地方。微服务把单体式框架中的组件，拆分成不同的服务，在构建它们时将会有更多的选择。分散治理也意味着责任的下放，每个团队对自己的业务服务负责，如果你维护一个 7x24 小时的不间断服务，那么你就必须 24 小时随时 OnCall，哪怕晚上 3 点起来处理问题，就是 AWS 的模式。
当单体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。这一点，我们后面会详细说明。
云计算，特别是 AWS、Azure、Aliyun 等的发展，减少了构建、发布、运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化。其实不管是运维，测试也是一样。 任务服务都可能因为供应商或者底层硬件或网络的不可靠而故障。微服务应为每个应用的服务及数据中心提供日常故障检测和恢复，收集各项系统状态指标和业务指标、日志信息进行监控，并提供预警报警能力。面向失败的设计，后面也会再讨论。
组件的关键特性是可替代性和可升级性，由于设计会不断更改，微服务所提供的服务应该能够替换或者报废，而不是要长久的发展的，每种设计也一样都有自己的阶段使命和生命周期。
这样如果客户需要兼容性，版本控制是一种好的手段。
以上。 |
|
发表于 2023-7-14 21:11:58