前言
今年软考，集中的备考时间为10月国庆节前后；
其中，上午综合题备考为"软考通"app刷题；
案例题备考参考的希塞官网的历年真题，带答案分析，非常方便总结；
论文备考，因为工作时间关系，只准备了一篇三层C/S架构；
但是四个论题中没有考架构风格，不过考到了微服务；
所以，我将数据库内容一笔带过，扩展了服务层的内容；
补充了RPC微服务通信，微服务优点等内容；
注意论文写完，一定要检查全篇，可以修改错别字，调整语句不通顺的地方。
下面贴出我考前准备的三层C/S架构草稿供参考，交卷论文在后30-40%内容上有调整。
2021软考架构论文真题试题四《论微服务架构及其应用》
微服务提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。
请围绕“论微服务架构及其应用”论题，依次从以下三个方面进行论述。
1、概要叙述你所参与管理或开发的软件项目，以及你在其中所承担的主要工作。
2、简要描述微服务优点。
3、具体阐述如何基于微服务架构进行软件设计实现的。
论文草稿
摘要
总格子数为350，要是字和符号加起来超过350就没地方写了。
2019年3月，我参与了某互联网医疗公司的“WiNEX-HIT”项目建设，期间我担任系统架构师职位，负责架构设计和中间件选型等工作。该项目的目标，是使有限的医疗资源能更高效准确地服务于百姓，其主要包含电子病历，LIS检验，RIS检查，RP申请单，门诊等子系统。本文以该项目为例，主要讨论软件架构风格的具体应用。因院方对可靠安全和可用性要求很高，故我选用三层C/S架构作为该系统框架，其中数据层采用SQLServer；服务层采用Spring和Eureka等，并根据业务功能划分出若干微服务构件，能够灵活的进行组合配置；表示层含web和移动端等。项目开发历时13个月，最终顺利投产运行，并获得了各医院领导同事的一致好评。但是，该项目也存在不足，如系统发布时采用https协议进行数据传输，这远未达到院方对系统安全性的要求。
正文
总格子数为2750，建议写2350~2500字左右即可。
关于架构设计 实考时调整为关于微服务及其简介，将题干材料修改一下COPY过来。整个项目历时一年，于2020年4月成功发布，并已服务于各大合作医院。下面将详细介绍我设计的三层C/S架构。
首先表示层包含PC端，网页，安卓/iOS/PAD移动端，小程序，以及医院内各区域的显示屏，如走廊屏床头屏等。作为直接和用户交互的载体，我们的应用层分布范围非常广。技术方面，我采取了严格的前后端分离策略，应用层负责处理用户的输入和向客户的输出，所有的业务逻辑均由服务层处理。应用层提出需要的数据，服务端从数据库中获取并根据需求进行逻辑处理，之后通过RESTful风格封装的接口api，并以简洁清晰的json数据格式进行传输。这也带来另一个益处，服务端研发完成的业务构件可以供多端使用，如先前在web端上的在线电子病历系统，可以在不用更改服务的情况下，同时在安卓和ios等移动端开发该动能，即多个表示端能够并发，且快速的跟进同类业务的研发和上线。
其次服务层主要采用Spring，ActiveMQ，Docker和Eureka等技术。因为WiNEX系统体积大功能多，不可避免的会出现开发人员多，所需服务器规模大的情况。对此，我仔细梳理了整个系统需求，并选择基于构件的开发思想，拆分出若干边界清晰的子业务模块，如注册登录，设备管理，门诊医疗，住院管理，电子病历，处方管理，检查检验，消息推送等模块。在定义好各模块的对外接口后，各小组能够并行开发，在之后的集成联调过程中效率极高，并且便于进行代码管理和版本维护。项目研发阶段，我选择基于AOP的SpringBoot进行模块化开发，同时将公共逻辑封装为高内聚高可复用性的组件，置于公司的私有maven库，并补充详细的使用文档，以便扩展业务时有新增组件可直接依赖使用。此外，医院对于服务的可用性要求高，因此需要处理高并发问题，避免出现服务器瞬时负载过高而导致的请求失败问题，对此我选择了基于NIO的非阻塞网络请求框架Netty，同时配合消息中间件ActiveMQ，在接收到超过服务处理负荷的消息后，将该请求置于消息缓冲队列，待负荷达到能够处理的情况后，再取出请求并处理响应。
在系统的各个服务构件开发完成后，我选用Eureka服务发现框架来关联各个微服务，该框架满足CAP定理中的AP，即可用性和分区容错性，符合院方对可用性方面的需求。利用Eureka的轮询负载算法，心跳检查和客户端缓存机制等，能确保系统的高可用性，灵活性和伸缩性。另外，在服务部署方面，之前的经验是完全基于虚拟机，即每次新增服务节点时都要重复搭建虚拟机环境，效率较低。在该项目中，因为使用了基于构件的开发方法，我选用Docker进行服务部署。即使用Docker容器作为组件的载体，针对不同的服务组件，可以隔离搭建容器内环境，并且通过容器构建的镜像可以复用，以后增加的新组件可以依附于匹配其运行环境的镜像。同时我选择k8s集群管理来控制各个服务节点，优化负载均衡，其可与Docker无缝配合使用，降低了运维负担和部署成本。
最后数据层为SQLServer。对于医疗信息系统来说，数据层的重要性不言而喻，我们对主流数据库进行了对比选型，并与各数据库厂商深入沟通后，最终选择了微软的SQLServer作为核心数据库系统。同时，对于各个医院的定制化服务，我们对一些不敏感的数据使用MySQL进行存储，因为其比较稳定，性价比高，并且除了分页逻辑之外其他操作的处理与SQLServer基本一致。在开发过程中，我发现各业务研发组使用的数据访问技术不一致，JDBC和各种ORM框架都有使用。对此，我选择Mybatis来统一操作数据库，该框架使用成本低，开发效率高，和Spring兼容性好，很快便落地于所有项目组。由于用户对数据的访问具有集中性，所以我们基于Redis和SpringCache建立了缓存机制，降低对数据库访问的响应延迟。另外，在系统运行一段时间后，有医院反映某些特定页面刷新速度越来越慢，通过分析后我得出结论，因医院业务数据量大，导致有的表中在短时间内记录便达到上万条，从而导致查询变慢的情况出现。对此，我采取了水平分表方法，当表中记录到达五千条后，将新增记录转存至新的库中，并通过建立记录的插入时间和主码的索引，优化了单表数据量查询效率低的问题。同时考虑到数据库的物理安全性，我选用磁盘冗余阵列RAID5来存储数据，以减少一个磁盘容量为代价，换来了数据层稳定性和安全性的提升。
经过一年多的建设，WiNEX系统于2020年4月开发完成并顺利投产，当前，该系统正在为北京，上海，重庆等全国多家大型医院提供稳定高效的服务，在节省大量医疗成本的同时，让百姓得到了更好的就诊体验。根据以往项目经验，我们使用https协议，即在http的基础上通过传输加密和身份认证来保证信息传输过程的安全性。然而，院方指出这不满足其严格的要求标准，对此，我做了如下改进。对于注册登录系统，使用SpringSecurity和Token技术以增强用户身份验证，对于用户密码使用MD5并加盐，对于其他业务数据，采用DSA非对称加密算法，防止伪造身份进行非法请求和窃听消息等网络攻击。此外，我们将对院方数据库操作的服务部署在各院区内网，并添加网关服务，作为外网和院区服务的中介，通过在网关服务中添加用户和访问接口地址白名单，配合加密算法，保障了院方数据库的高安全性，同时也避免了客户端请求多个服务地址可能会出现的跨域问题。更进一步，我们将数字认证领域的龙头北京CA集成进系统，通过物理USB-Key和数字证书验证等方式，确保患者和医师在系统操作中的身份不可抵赖性，并具有法律效力。
实践证明，合适的架构设计是项目成功的基础。在系统建设中，我也发现了自身的不足，接下来我将勤于总结问题，通过持续的回顾，反思和探究，学习新技术，不断地提升架构设计能力，以建设质量更高的项目。
